Menu
▾
▴
tcl-core — Tcl Core Team discussions about Tcl development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
| 2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
| 2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
| 2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
| 2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
| 2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
| 2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
| 2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
| 2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
| 2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
| 2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
| 2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
| 2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
| 2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
| 2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
| 2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
| 2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
| 2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
| 2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
| 2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
| 2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
| 2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
| 2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(89) |
May
(60) |
Jun
(162) |
Jul
(201) |
Aug
(61) |
Sep
(167) |
Oct
(111) |
Nov
(133) |
Dec
(141) |
| 2025 |
Jan
(122) |
Feb
(88) |
Mar
(106) |
Apr
(113) |
May
(203) |
Jun
(185) |
Jul
(124) |
Aug
(202) |
Sep
(176) |
Oct
(3) |
Nov
|
Dec
|
|
From: Kevin W. <kw...@co...> - 2025-08-19 19:42:46
|
> On Aug 19, 2025, at 12:50 PM, Marc Culler <cul...@gm...> wrote: > > I think these are overlapping, but distinct, application domains. I understand the distinction. I’m surprised that my interest in IPC across apps seems so out of step. |
|
From: Marc C. <cul...@gm...> - 2025-08-19 16:50:20
|
On Mon, Aug 18, 2025 at 3:13 PM Kevin Walzer <kw...@co...> wrote:
> We already have platform-native IPC methods on macOS and win32.
>
> Mac: Tk has basic integration with AppleScript/Apple Events, which means
> that any AppleScript client can send a message to Wish with the AppleScript
> command "do script," in which Wish will execute whatever Tcl code is
> contained in the body of the "script."
>
Well, it isn't quite that simple. I think what is true is that the Wish
app supports the AppleScript command "do script".
If you start tclsh and run `package require Tk` you cannot talk to that Tk
application with AppleScript. Although an NSApplication object does get
created when you do that, it does not appear as an "Application" as far as
AppleScript is concerned. If you load Tk into tclsh and use Script Editor
to run the AppleScript program:
tell Application "Wish"
do script "pid"
end tell
a new instance of Wish.app will be launched and nothing will be printed in
the result box. But if the Wish app is running then the same script prints
a pid.
The send command is meant to communicate between two Tcl interpreters which
have loaded Tk (although on the mac they currently have to be in the same
process)..
So I think these are overlapping, but distinct, application domains.
- Marc
|
|
From: Marc C. <cul...@gm...> - 2025-08-19 12:40:47
|
TIP #726: YES - Marc On Mon, Aug 18, 2025 at 9:19 PM apnmbx-public--- via Tcl-Core < tcl...@li...> wrote: > This is a CFV for TIP 726: Commands for Unicode normalization > <https://core.tcl-lang.org/tips/doc/trunk/tip/726.md> > > > > CFV ends 2025-08-29 00:00 UTC. > > > > My vote: Yes > > > > /Ashok > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Kevin W. <kw...@co...> - 2025-08-19 11:02:06
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">TIP 726: YES</div><div dir="ltr"><br><blockquote type="cite">On Aug 18, 2025, at 10:19 PM, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Aptos; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif; }
span.EmailStyle17 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 11pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div class="WordSection1"><p class="MsoNormal">This is a CFV for <a href="https://core.tcl-lang.org/tips/doc/trunk/tip/726.md"><span style="color:blue">TIP 726: Commands for Unicode normalization</span></a> <o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">CFV ends 2025-08-29 00:00 UTC.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My vote: Yes<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">/Ashok<o:p></o:p></p></div><span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html> |
|
From: Kevin W. <kw...@co...> - 2025-08-19 10:37:09
|
> On Aug 19, 2025, at 3:32 AM, Erik Leunissen via Tcl-Core <tcl...@li...> wrote: > > But I never understood what business a display server / windowing system has in > providing an IPC mechanism (or a "backdoor") if you will Automation - the ability to programmatically drive various applications and have them work together in different ways- is just as powerful and useful in a GUI environment as a shell environment. An entire publishing automation industry grew up around AppleScript driving complex Adobe and Quark product workflows in the 1990s. Windows Script Host provides a similar capability. And apps are far more useful if they can be plugged into these automation workflows. No one has ever suggested removing the ability of shell scripts to drive complex CLI workflows. I don’t understand why people argue differently with GUI apps. To me, it’s self-evident. |
|
From: Jan N. <jan...@gm...> - 2025-08-19 08:50:01
|
Op di 19 aug 2025 om 04:19 schreef Ashok:
> This is a CFV for TIP 726: Commands for Unicode normalization
My vote.
TIP #726 YES
On my wish-list: "string tolower -locale <locale> <string>". Like
the C++ std::tolower(). But that would be a separate TIP
(I don't even know if utf8proc can do that). ;-)
Hope this helps,
Jan Nijtmans
|
|
From: Harald O. <har...@el...> - 2025-08-19 07:36:53
|
Am 19.08.2025 um 04:19 schrieb apnmbx-public--- via Tcl-Core: > This is a CFV for TIP 726: Commands for Unicode normalization <https:// > core.tcl-lang.org/tips/doc/trunk/tip/726.md> > > CFV ends 2025-08-29 00:00 UTC. Yes ! Thanks for all, Harald |
|
From: Harald O. <har...@el...> - 2025-08-19 07:36:29
|
It might be a good idea to make a TIP for Tk to reform send and eventually remove it. Tk has IMHO a lot of old stufdf in which may be removed: - suppored for displays with index colors - virtual screen (winfo vroot vs winfo root) Thanks for all, Harald |
|
From: Erik L. <el...@xs...> - 2025-08-19 07:31:48
|
On 8/19/25 09:21, Erik Leunissen via Tcl-Core wrote: > On 8/19/25 05:12, Brian Griffin wrote: >> To expand on what others have said, having “send” builtin and blindly available makes the attack >> surface potentially riskier. >> >> A better approach would be to provide a quasi-standardized mechanism that must be explicitly >> enabled by the application, would be more reasonable. >> > > I couldn't agree more. > > If you decide to provide this functionality, then make the disabled state the > default. Let users opt-in instead of opt-out. > But I never understood what business a display server / windowing system has in providing an IPC mechanism (or a "backdoor") if you will. My two cents. Erik. -- > Erik. > -- > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Erik L. <el...@xs...> - 2025-08-19 07:21:17
|
On 8/19/25 05:12, Brian Griffin wrote: > To expand on what others have said, having “send” builtin and blindly available makes the attack > surface potentially riskier. > > A better approach would be to provide a quasi-standardized mechanism that must be explicitly enabled > by the application, would be more reasonable. > I couldn't agree more. If you decide to provide this functionality, then make the disabled state the default. Let users opt-in instead of opt-out. Erik. -- |
|
From: Brian G. <bri...@ea...> - 2025-08-19 04:47:01
|
To expand on what others have said, having “send” builtin and blindly available makes the attack surface potentially riskier. A better approach would be to provide a quasi-standardized mechanism that must be explicitly enabled by the application, would be more reasonable. -Brian (from mobile device) On Aug 18, 2025, at 13:29, Kevin Kenny <kev...@gm...> wrote: On Mon, Aug 18, 2025 at 1:50 PM Marc Culler <cul...@gm...<mailto:cul...@gm...>> wrote: A more detailed followup question after AI informed me that send is used by tkinspect.: What if Tk were to post a dialog box requesting permission to accept send commands from a specific sender? Would that deal with the security implications, while still allowing programs like tkinspect to use it? My memory may be faulty, but I understand that tkinspect (which is itself an orphaned extension), and the equally orphaned TDK Inspector, were at some point modified to use 'comm' instead of send. The 'comm' extension required a small piece of code in the target process that had a socket listener listening at a known port. Obviously, a mechanism for authentication and authorization could be wrapped around that, in much the same way that any application server or database server has authentication mechanisms built in. [send] is only slightly more insecure than X11 itself. where a malicious application that has access to the X server can command any other application on the same desktop by an event injection attack. 'Shatter' attacks on Windows were a similar attack, non-Tk-related, that allowed code injection into any process running the Windows message loop. (This insecurity was partially plugged by isolating the session of processes with elevated privilege.) I've personally considered [send] to be a pretty dodgy approach for IPC for at least twenty years. I'd not cry to see it deprecated. Alas, Tcl/Tk has no good deprecation mechanism, which is horribly difficult to implement in such an aggressively dynamic language. (That's a separate issue, for which I suspect that Peter Spjuth's code-analysis tools might provide a partial solution.) The requirement to launch an interactor in the target process is fairly benign. If the consensus is that the interactor should always be there, then launching it from Tk's initialization, and having it request permission on first connection, as Marc suggests, would indeed be a possibility. In place of asking permission, another possibility would be for the interactor to generate a session key and store it in a secure location, and then expect the controlling process to present that session key. That would avoid an awkward dialog in the controlled process, and allow inspection of any process running the event loop, rather than being limited to Tk. -- 73 de ke9tv/2, Kevin _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Kevin W. <kw...@co...> - 2025-08-19 03:15:36
|
> On Aug 18, 2025, at 5:40 PM, da Silva, Peter J <pet...@fl...> wrote: > > Limited use for people trying to write portable software I’ll just add my view that the best software is a good citizen on whatever platform it runs on - which means a portable core supplemented by appropriate integration with native APIs. |
|
From: <apn...@ya...> - 2025-08-19 02:51:13
|
The tcllib repository seems to have forked into having two branches name trunk. Clif, I *think* it's your commit and if so may want to resolve by merging. /Ashok |
|
From: <apn...@ya...> - 2025-08-19 02:19:19
|
This is a CFV for <https://core.tcl-lang.org/tips/doc/trunk/tip/726.md> TIP 726: Commands for Unicode normalization CFV ends 2025-08-29 00:00 UTC. My vote: Yes /Ashok |
|
From: da S. P. J <pet...@fl...> - 2025-08-18 21:44:02
|
> [send] is only slightly more insecure than X11 itself Damning with faint praise. xhost +, y’all |
|
From: da S. P. J <pet...@fl...> - 2025-08-18 21:40:34
|
> We already have platform-native IPC methods on macOS and win32. Limited use for people trying to write portable software. |
|
From: Kevin K. <kev...@gm...> - 2025-08-18 20:28:45
|
On Mon, Aug 18, 2025 at 1:50 PM Marc Culler <cul...@gm...> wrote: > A more detailed followup question after AI informed me that send is used > by tkinspect.: > > What if Tk were to post a dialog box requesting permission to accept send > commands from a specific sender? Would that deal with the security > implications, while still allowing programs like tkinspect to use it? > > My memory may be faulty, but I understand that tkinspect (which is itself an orphaned extension), and the equally orphaned TDK Inspector, were at some point modified to use 'comm' instead of send. The 'comm' extension required a small piece of code in the target process that had a socket listener listening at a known port. Obviously, a mechanism for authentication and authorization could be wrapped around that, in much the same way that any application server or database server has authentication mechanisms built in. [send] is only slightly more insecure than X11 itself. where a malicious application that has access to the X server can command any other application on the same desktop by an event injection attack. 'Shatter' attacks on Windows were a similar attack, non-Tk-related, that allowed code injection into any process running the Windows message loop. (This insecurity was partially plugged by isolating the session of processes with elevated privilege.) I've personally considered [send] to be a pretty dodgy approach for IPC for at least twenty years. I'd not cry to see it deprecated. Alas, Tcl/Tk has no good deprecation mechanism, which is horribly difficult to implement in such an aggressively dynamic language. (That's a separate issue, for which I suspect that Peter Spjuth's code-analysis tools might provide a partial solution.) The requirement to launch an interactor in the target process is fairly benign. If the consensus is that the interactor should always be there, then launching it from Tk's initialization, and having it request permission on first connection, as Marc suggests, would indeed be a possibility. In place of asking permission, another possibility would be for the interactor to generate a session key and store it in a secure location, and then expect the controlling process to present that session key. That would avoid an awkward dialog in the controlled process, and allow inspection of any process running the event loop, rather than being limited to Tk. -- 73 de ke9tv/2, Kevin |
|
From: Kevin W. <kw...@co...> - 2025-08-18 20:13:16
|
We already have platform-native IPC methods on macOS and win32. Mac: Tk has basic integration with AppleScript/Apple Events, which means that any AppleScript client can send a message to Wish with the AppleScript command "do script," in which Wish will execute whatever Tcl code is contained in the body of the "script." Wish can also execute AppleScript code via the "osascript" command-line tool. (There is also an AppleScript extension that does the same thing directly inline from Tcl, but I'm focused on the core.) Windows: Tcl has supported the dde package forever. DDE is an ancient protocol for sending data over window messages between apps, and there aren't may clients that support it, but Tcl's implementation is rock solid. Linux: Nothing built in, but the obvious choice would be to incoporate all or some of Schelte Bron's tcl-dbus and dbif packages that make Tcl/Tk both a dbus client and server that can be accessed from other apps via "dbus-send" or other tool. I would support a TIP to get this done but am unable to take the work on myself. I have never quite understood the security issues around these protocols--I am strongly in favor of robust IPC support in the platform-native protocol, and I support this in all my Tcl/Tk apps. "send," on the other hand, has always struck me as a curiosity of dubious utility. --Kevin On 8/18/25 3:57 PM, da Silva, Peter J wrote: > > > What do you see as the bothersome security implications of /send/? > > That it executes code in the destination process makes it a huge > potential attack surface. > > > What features would a new IPC mechanism need to have in order to avoid > those implications? > > > Not execute code, just pass a block of data that the recipient can > deal with as untrusted content and filter, encapsulate, or otherwise > handle. > > > To paraphrase Kevin's comment, why not just eliminate the /send/ > command altogether? > > Then you don’t have a supported Tcl-level IPC mechanism. Which is > actually an acceptable outcome. > > *From: *Marc Culler <cul...@gm...> > *Date: *Monday, August 18, 2025 at 12:42 > *To: *da Silva, Peter J (USA) <pet...@fl...> > *Cc: *Kevin Walzer <kw...@co...>, > tcl...@li... <tcl...@li...> > *Subject: *Re: [TCLCORE] Advice requested regarding [send] on macOS > > Hi Peter, I have three questions: * What do you see as the bothersome > security implications of send? * What features would a new IPC > mechanism need to have in order to avoid those implications? * To > paraphrase Kevin's comment, why not just > > Hi Peter, > > I have three questions: > > * What do you see as the bothersome security implications of /send/? > > * What features would a new IPC mechanism need to have in order to > avoid those implications? > > * To paraphrase Kevin's comment, why not just eliminate the /send/ > command altogether? > > - Marc > > PS Does flightaware use the /send/ command? Does anyone? > > On Mon, Aug 18, 2025 at 9:33 AM da Silva, Peter J > <pet...@fl...> wrote: > > I suspect that it might be best to start to deprecate send and > brainstorm a new and less problematic IPC mechanism. Because the > security implications of send have bothered me from the start. > > *From: *Kevin Walzer <kw...@co...> > *Date: *Saturday, August 16, 2025 at 23:06 > *To: *Marc Culler <cul...@gm...> > *Cc: *tcl...@li... <tcl...@li...> > *Subject: *Re: [TCLCORE] Advice requested regarding [send] on macOS > > Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t > send disabled on win32 because its COM-based implementation wa > deemed a security risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler > <culler. x@ gmail. com> wrote: Erik, I now > > Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t > send disabled on win32 because its COM-based implementation wa > deemed a security risk? > > On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...> > wrote: > > > > Erik, > > I now think that much of what I said about the consequences of > having a unique NSApplication object is wrong. I think there > is actually no obstacle to implementing a send command on > macOS which can send commands to interpreters in a different > Wish process. The only problem is that no one ever wrote such > an implementation. > > - Marc > > On Sat, Aug 16, 2025 at 7:17 AM Marc Culler > <cul...@gm...> wrote: > > Apple does provide IPC mechanisms. I don't know whether > they would be suitable, but I am pretty sure they would. > However, the current implementation of [send] does not > attempt to use them. If you look at the top of > macosx/TkMacOSXSend.c you will see this very old comment > (note that "gestalts" no longer exist in macOS): > > * This file provides procedures that implement the > "send" command, > * allowing commands to be passed from interpreter to > interpreter. This > * current implementation for the Mac has most > functionality stubbed out. > * > * The current plan, which we have not had time to > implement, is for the > * first Wish app to create a gestalt of type 'WIsH'. > This gestalt will > * point to a table, in system memory, of Tk apps. > Each Tk app, when it > * starts up, will register their name, and process > ID, in this table. > * This will allow us to implement "tk appname". > * > * Then the send command will look up the process id > of the target app in > * this table, and send an AppleEvent to that > process. The AppleEvent > * handler is much like the do script handler, except > that you have to > * specify the name of the tk app as well, since > there may be many > * interps in one wish app, and you need to send it > to the right one. > * > * Implementing this has been on our list of things > to do, but what with > * the demise of Tcl at Sun, and the lack of > resources at Scriptics it > * may not get done for awhile. So this sketch is > offered for the brave > * to attempt if they need the functionality... > > - Marc > > On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows > <don...@ma...> wrote: > > I would be very startled if it /isn't/ the exact same > issue, a combination of needing a suitable IPC > mechanism for doing the discovery and communications, > and system policy restricting access to such things > even if they exist. > > Donal. > > ------------------------------------------------------------------------ > > *From:* Erik Leunissen via Tcl-Core > <tcl...@li...> > *Sent:* Saturday, August 16, 2025 07:12 > *To:* Marc Culler <cul...@gm...> > *Cc:* tcl...@li... > <tcl...@li...> > *Subject:* Re: [TCLCORE] Advice requested regarding > [send] on macOS > > Related to this matter: I noticed (in a debug > statement issued by me for execution at Github) that > interpreters in another process are not returned by > [winfo interps] on macOS. (See the script below > to verify that). I'm suspecting that this is for the > very same reason/cause. Can you please give your view > about that (confirm/deny if > possible) ? > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> > |
|
From: da S. P. J <pet...@fl...> - 2025-08-18 19:58:03
|
> What do you see as the bothersome security implications of send? That it executes code in the destination process makes it a huge potential attack surface. > What features would a new IPC mechanism need to have in order to avoid those implications? Not execute code, just pass a block of data that the recipient can deal with as untrusted content and filter, encapsulate, or otherwise handle. > To paraphrase Kevin's comment, why not just eliminate the send command altogether? Then you don’t have a supported Tcl-level IPC mechanism. Which is actually an acceptable outcome. From: Marc Culler <cul...@gm...> Date: Monday, August 18, 2025 at 12:42 To: da Silva, Peter J (USA) <pet...@fl...> Cc: Kevin Walzer <kw...@co...>, tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Hi Peter, I have three questions: * What do you see as the bothersome security implications of send? * What features would a new IPC mechanism need to have in order to avoid those implications? * To paraphrase Kevin's comment, why not just Hi Peter, I have three questions: * What do you see as the bothersome security implications of send? * What features would a new IPC mechanism need to have in order to avoid those implications? * To paraphrase Kevin's comment, why not just eliminate the send command altogether? - Marc PS Does flightaware use the send command? Does anyone? On Mon, Aug 18, 2025 at 9:33 AM da Silva, Peter J <pet...@fl...<mailto:pet...@fl...>> wrote: I suspect that it might be best to start to deprecate send and brainstorm a new and less problematic IPC mechanism. Because the security implications of send have bothered me from the start. From: Kevin Walzer <kw...@co...<mailto:kw...@co...>> Date: Saturday, August 16, 2025 at 23:06 To: Marc Culler <cul...@gm...<mailto:cul...@gm...>> Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler <culler. x@ gmail. com> wrote: Erik, I now Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...<mailto:cul...@gm...>> wrote: Erik, I now think that much of what I said about the consequences of having a unique NSApplication object is wrong. I think there is actually no obstacle to implementing a send command on macOS which can send commands to interpreters in a different Wish process. The only problem is that no one ever wrote such an implementation. - Marc On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...<mailto:cul...@gm...>> wrote: Apple does provide IPC mechanisms. I don't know whether they would be suitable, but I am pretty sure they would. However, the current implementation of [send] does not attempt to use them. If you look at the top of macosx/TkMacOSXSend.c you will see this very old comment (note that "gestalts" no longer exist in macOS): * This file provides procedures that implement the "send" command, * allowing commands to be passed from interpreter to interpreter. This * current implementation for the Mac has most functionality stubbed out. * * The current plan, which we have not had time to implement, is for the * first Wish app to create a gestalt of type 'WIsH'. This gestalt will * point to a table, in system memory, of Tk apps. Each Tk app, when it * starts up, will register their name, and process ID, in this table. * This will allow us to implement "tk appname". * * Then the send command will look up the process id of the target app in * this table, and send an AppleEvent to that process. The AppleEvent * handler is much like the do script handler, except that you have to * specify the name of the tk app as well, since there may be many * interps in one wish app, and you need to send it to the right one. * * Implementing this has been on our list of things to do, but what with * the demise of Tcl at Sun, and the lack of resources at Scriptics it * may not get done for awhile. So this sketch is offered for the brave * to attempt if they need the functionality... - Marc On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows <don...@ma...<mailto:don...@ma...>> wrote: I would be very startled if it isn't the exact same issue, a combination of needing a suitable IPC mechanism for doing the discovery and communications, and system policy restricting access to such things even if they exist. Donal. ________________________________ From: Erik Leunissen via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> Sent: Saturday, August 16, 2025 07:12 To: Marc Culler <cul...@gm...<mailto:cul...@gm...>> Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that interpreters in another process are not returned by [winfo interps] on macOS. (See the script below to verify that). I'm suspecting that this is for the very same reason/cause. Can you please give your view about that (confirm/deny if possible) ? _______________________________________________ Tcl-Core mailing list Tcl...@li...<mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> |
|
From: Brian G. <bri...@ea...> - 2025-08-18 19:36:22
|
On Aug 18, 2025, at 07:34, da Silva, Peter J <pet...@fl...> wrote: I suspect that it might be best to start to deprecate send and brainstorm a new and less problematic IPC mechanism. Because the security implications of send have bothered me from the start. +1 -Brian From: Kevin Walzer <kw...@co...> Date: Saturday, August 16, 2025 at 23:06 To: Marc Culler <cul...@gm...> Cc: tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler <culler. x@ gmail. com> wrote: Erik, I now Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...> wrote: Erik, I now think that much of what I said about the consequences of having a unique NSApplication object is wrong. I think there is actually no obstacle to implementing a send command on macOS which can send commands to interpreters in a different Wish process. The only problem is that no one ever wrote such an implementation. - Marc On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...<mailto:cul...@gm...>> wrote: Apple does provide IPC mechanisms. I don't know whether they would be suitable, but I am pretty sure they would. However, the current implementation of [send] does not attempt to use them. If you look at the top of macosx/TkMacOSXSend.c you will see this very old comment (note that "gestalts" no longer exist in macOS): * This file provides procedures that implement the "send" command, * allowing commands to be passed from interpreter to interpreter. This * current implementation for the Mac has most functionality stubbed out. * * The current plan, which we have not had time to implement, is for the * first Wish app to create a gestalt of type 'WIsH'. This gestalt will * point to a table, in system memory, of Tk apps. Each Tk app, when it * starts up, will register their name, and process ID, in this table. * This will allow us to implement "tk appname". * * Then the send command will look up the process id of the target app in * this table, and send an AppleEvent to that process. The AppleEvent * handler is much like the do script handler, except that you have to * specify the name of the tk app as well, since there may be many * interps in one wish app, and you need to send it to the right one. * * Implementing this has been on our list of things to do, but what with * the demise of Tcl at Sun, and the lack of resources at Scriptics it * may not get done for awhile. So this sketch is offered for the brave * to attempt if they need the functionality... - Marc On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows <don...@ma...<mailto:don...@ma...>> wrote: I would be very startled if it isn't the exact same issue, a combination of needing a suitable IPC mechanism for doing the discovery and communications, and system policy restricting access to such things even if they exist. Donal. ________________________________ From: Erik Leunissen via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> Sent: Saturday, August 16, 2025 07:12 To: Marc Culler <cul...@gm...<mailto:cul...@gm...>> Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that interpreters in another process are not returned by [winfo interps] on macOS. (See the script below to verify that). I'm suspecting that this is for the very same reason/cause. Can you please give your view about that (confirm/deny if possible) ? _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Stuart C. <exo...@ya...> - 2025-08-18 19:05:23
|
Hi, On OpenBSD: My only real concern would be the Thread extension, which, if not made to work in 8 and 9, would have to be separate extension: tclthread and tcl9thread. Not great, not terrible. Right now, everything 8/9 is as integrated as possible but separated where necessary. Tcl/Tk 8.5 and 8.6 are installed under dir names "8.5" and "8.6". Tcl/Tk 9 will simply be "9". When 9.1 is released, it will replace 9.0. The paths and dirs for 9 will be similar, but I'll be keeping the older naming convention for libs and maybe other things, ie: libtk90.so instead of libtcl9tk90.so. These are the default auto_path and tm paths: $ tclsh8.6 % set auto_path /usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl % tcl::tm::path list /usr/local/lib/tcl/modules/85 /usr/local/lib/tcl/modules/86 /usr/local/lib/tcl/tcl8.6/modules Here's the packing list for 8.6: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/PLIST?rev=1.17&content-type=text/plain Here's a snip of the most important bits of the package readme: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/README?rev=1.8&content-type=text/plain Tclsh and Wish -------------- normally /usr/local/lib/tclsh, /usr/local/lib/wish now /usr/local/bin/tclsh8.6, /usr/local/bin/wish8.6 Library files ------------- scripts, encoding files, etc. normally in /usr/local/lib/tcl8.6, /usr/local/lib/tk8.6 now in /usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6 Configuration Files ------------------- tclConfig.sh, tkConfig.sh normally in /usr/local/lib now in /usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6 Header Files ------------ *.h normally in /usr/local/include now in /usr/local/include/tcl8.6, /usr/local/include/tk8.6 Manual Pages ------------ *.1, *.3, *.n normally in /usr/local/man now in /usr/local/lib/tcl/tcl8.6/man, /usr/local/lib/tcl/tk8.6/man Demos ----- *.tcl, * normally in /usr/local/lib/tk8.6/demos now in /usr/local/share/examples/tk8.6 Bundled Tcl Modules ------------------- *.tm normally in /usr/local/lib/tcl8/... now in /usr/local/lib/tcl/tcl8.6/modules Tcl Module Paths ---------------- normally /usr/local/lib/tcl8/... now /usr/local/lib/tcl/modules/{85,86} Manual Page Configuration ========================= Adding the following lines to /etc/man.conf wil enable man(1) and related commands can find the Tcl and Tk manual pages. manpath /usr/local/lib/tcl/tcl8.6/man manpath /usr/local/lib/tcl/tk8.6/man Stu |
|
From: Marc C. <cul...@gm...> - 2025-08-18 17:50:10
|
A more detailed followup question after AI informed me that send is used by tkinspect.: What if Tk were to post a dialog box requesting permission to accept send commands from a specific sender? Would that deal with the security implications, while still allowing programs like tkinspect to use it? - Marc On Mon, Aug 18, 2025 at 12:42 PM Marc Culler <cul...@gm...> wrote: > Hi Peter, > > I have three questions: > > * What do you see as the bothersome security implications of *send*? > * What features would a new IPC mechanism need to have in order to avoid > those implications? > * To paraphrase Kevin's comment, why not just eliminate the *send* > command altogether? > > - Marc > > PS Does flightaware use the *send* command? Does anyone? > > > On Mon, Aug 18, 2025 at 9:33 AM da Silva, Peter J < > pet...@fl...> wrote: > >> I suspect that it might be best to start to deprecate send and brainstorm >> a new and less problematic IPC mechanism. Because the security implications >> of send have bothered me from the start. >> >> >> >> *From: *Kevin Walzer <kw...@co...> >> *Date: *Saturday, August 16, 2025 at 23:06 >> *To: *Marc Culler <cul...@gm...> >> *Cc: *tcl...@li... <tcl...@li...> >> *Subject: *Re: [TCLCORE] Advice requested regarding [send] on macOS >> >> Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send >> disabled on win32 because its COM-based implementation wa deemed a security >> risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler <culler. x@ gmail. com> >> wrote: Erik, I now >> >> Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send >> disabled on win32 because its COM-based implementation wa deemed a security >> risk? >> >> >> >> On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...> wrote: >> >> >> >> Erik, >> >> >> >> I now think that much of what I said about the consequences of having a >> unique NSApplication object is wrong. I think there is actually no >> obstacle to implementing a send command on macOS which can send commands to >> interpreters in a different Wish process. The only problem is that no one >> ever wrote such an implementation. >> >> >> >> - Marc >> >> >> >> On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...> wrote: >> >> Apple does provide IPC mechanisms. I don't know whether they would be >> suitable, but I am pretty sure they would. However, the current >> implementation of [send] does not attempt to use them. If you look at the >> top of macosx/TkMacOSXSend.c you will see this very old comment (note that >> "gestalts" no longer exist in macOS): >> >> >> >> * This file provides procedures that implement the "send" command, >> * allowing commands to be passed from interpreter to interpreter. >> This >> * current implementation for the Mac has most functionality stubbed >> out. >> * >> * The current plan, which we have not had time to implement, is for >> the >> * first Wish app to create a gestalt of type 'WIsH'. This gestalt >> will >> * point to a table, in system memory, of Tk apps. Each Tk app, when >> it >> * starts up, will register their name, and process ID, in this >> table. >> * This will allow us to implement "tk appname". >> * >> * Then the send command will look up the process id of the target >> app in >> * this table, and send an AppleEvent to that process. The AppleEvent >> * handler is much like the do script handler, except that you have >> to >> * specify the name of the tk app as well, since there may be many >> * interps in one wish app, and you need to send it to the right one. >> * >> * Implementing this has been on our list of things to do, but what >> with >> * the demise of Tcl at Sun, and the lack of resources at Scriptics >> it >> * may not get done for awhile. So this sketch is offered for the >> brave >> * to attempt if they need the functionality... >> >> >> >> - Marc >> >> >> >> >> >> On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows < >> don...@ma...> wrote: >> >> I would be very startled if it *isn't* the exact same issue, a >> combination of needing a suitable IPC mechanism for doing the discovery and >> communications, and system policy restricting access to such things even if >> they exist. >> >> >> >> Donal. >> >> >> ------------------------------ >> >> *From:* Erik Leunissen via Tcl-Core <tcl...@li...> >> *Sent:* Saturday, August 16, 2025 07:12 >> *To:* Marc Culler <cul...@gm...> >> *Cc:* tcl...@li... <tcl...@li...> >> *Subject:* Re: [TCLCORE] Advice requested regarding [send] on macOS >> >> >> >> Related to this matter: I noticed (in a debug statement issued by me for >> execution at Github) that >> interpreters in another process are not returned by [winfo interps] on >> macOS. (See the script below >> to verify that). I'm suspecting that this is for the >> very same reason/cause. Can you please give your view about that >> (confirm/deny if >> possible) ? >> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core >> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> >> >> |
|
From: Marc C. <cul...@gm...> - 2025-08-18 17:42:30
|
Hi Peter, I have three questions: * What do you see as the bothersome security implications of *send*? * What features would a new IPC mechanism need to have in order to avoid those implications? * To paraphrase Kevin's comment, why not just eliminate the *send* command altogether? - Marc PS Does flightaware use the *send* command? Does anyone? On Mon, Aug 18, 2025 at 9:33 AM da Silva, Peter J < pet...@fl...> wrote: > I suspect that it might be best to start to deprecate send and brainstorm > a new and less problematic IPC mechanism. Because the security implications > of send have bothered me from the start. > > > > *From: *Kevin Walzer <kw...@co...> > *Date: *Saturday, August 16, 2025 at 23:06 > *To: *Marc Culler <cul...@gm...> > *Cc: *tcl...@li... <tcl...@li...> > *Subject: *Re: [TCLCORE] Advice requested regarding [send] on macOS > > Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send > disabled on win32 because its COM-based implementation wa deemed a security > risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler <culler. x@ gmail. com> > wrote: Erik, I now > > Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send > disabled on win32 because its COM-based implementation wa deemed a security > risk? > > > > On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...> wrote: > > > > Erik, > > > > I now think that much of what I said about the consequences of having a > unique NSApplication object is wrong. I think there is actually no > obstacle to implementing a send command on macOS which can send commands to > interpreters in a different Wish process. The only problem is that no one > ever wrote such an implementation. > > > > - Marc > > > > On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...> wrote: > > Apple does provide IPC mechanisms. I don't know whether they would be > suitable, but I am pretty sure they would. However, the current > implementation of [send] does not attempt to use them. If you look at the > top of macosx/TkMacOSXSend.c you will see this very old comment (note that > "gestalts" no longer exist in macOS): > > > > * This file provides procedures that implement the "send" command, > * allowing commands to be passed from interpreter to interpreter. > This > * current implementation for the Mac has most functionality stubbed > out. > * > * The current plan, which we have not had time to implement, is for > the > * first Wish app to create a gestalt of type 'WIsH'. This gestalt > will > * point to a table, in system memory, of Tk apps. Each Tk app, when > it > * starts up, will register their name, and process ID, in this table. > * This will allow us to implement "tk appname". > * > * Then the send command will look up the process id of the target > app in > * this table, and send an AppleEvent to that process. The AppleEvent > * handler is much like the do script handler, except that you have to > * specify the name of the tk app as well, since there may be many > * interps in one wish app, and you need to send it to the right one. > * > * Implementing this has been on our list of things to do, but what > with > * the demise of Tcl at Sun, and the lack of resources at Scriptics it > * may not get done for awhile. So this sketch is offered for the > brave > * to attempt if they need the functionality... > > > > - Marc > > > > > > On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows < > don...@ma...> wrote: > > I would be very startled if it *isn't* the exact same issue, a > combination of needing a suitable IPC mechanism for doing the discovery and > communications, and system policy restricting access to such things even if > they exist. > > > > Donal. > > > ------------------------------ > > *From:* Erik Leunissen via Tcl-Core <tcl...@li...> > *Sent:* Saturday, August 16, 2025 07:12 > *To:* Marc Culler <cul...@gm...> > *Cc:* tcl...@li... <tcl...@li...> > *Subject:* Re: [TCLCORE] Advice requested regarding [send] on macOS > > > > Related to this matter: I noticed (in a debug statement issued by me for > execution at Github) that > interpreters in another process are not returned by [winfo interps] on > macOS. (See the script below > to verify that). I'm suspecting that this is for the > very same reason/cause. Can you please give your view about that > (confirm/deny if > possible) ? > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> > > |
|
From: da S. P. J <pet...@fl...> - 2025-08-18 14:33:50
|
I suspect that it might be best to start to deprecate send and brainstorm a new and less problematic IPC mechanism. Because the security implications of send have bothered me from the start. From: Kevin Walzer <kw...@co...> Date: Saturday, August 16, 2025 at 23:06 To: Marc Culler <cul...@gm...> Cc: tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11: 40 PM, Marc Culler <culler. x@ gmail. com> wrote: Erik, I now Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk? On Aug 16, 2025, at 11:40 PM, Marc Culler <cul...@gm...> wrote: Erik, I now think that much of what I said about the consequences of having a unique NSApplication object is wrong. I think there is actually no obstacle to implementing a send command on macOS which can send commands to interpreters in a different Wish process. The only problem is that no one ever wrote such an implementation. - Marc On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...<mailto:cul...@gm...>> wrote: Apple does provide IPC mechanisms. I don't know whether they would be suitable, but I am pretty sure they would. However, the current implementation of [send] does not attempt to use them. If you look at the top of macosx/TkMacOSXSend.c you will see this very old comment (note that "gestalts" no longer exist in macOS): * This file provides procedures that implement the "send" command, * allowing commands to be passed from interpreter to interpreter. This * current implementation for the Mac has most functionality stubbed out. * * The current plan, which we have not had time to implement, is for the * first Wish app to create a gestalt of type 'WIsH'. This gestalt will * point to a table, in system memory, of Tk apps. Each Tk app, when it * starts up, will register their name, and process ID, in this table. * This will allow us to implement "tk appname". * * Then the send command will look up the process id of the target app in * this table, and send an AppleEvent to that process. The AppleEvent * handler is much like the do script handler, except that you have to * specify the name of the tk app as well, since there may be many * interps in one wish app, and you need to send it to the right one. * * Implementing this has been on our list of things to do, but what with * the demise of Tcl at Sun, and the lack of resources at Scriptics it * may not get done for awhile. So this sketch is offered for the brave * to attempt if they need the functionality... - Marc On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows <don...@ma...<mailto:don...@ma...>> wrote: I would be very startled if it isn't the exact same issue, a combination of needing a suitable IPC mechanism for doing the discovery and communications, and system policy restricting access to such things even if they exist. Donal. ________________________________ From: Erik Leunissen via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> Sent: Saturday, August 16, 2025 07:12 To: Marc Culler <cul...@gm...<mailto:cul...@gm...>> Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>> Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that interpreters in another process are not returned by [winfo interps] on macOS. (See the script below to verify that). I'm suspecting that this is for the very same reason/cause. Can you please give your view about that (confirm/deny if possible) ? _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwQFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=MRY73X9ardiH_tlKyiI4jZU_sx8P9_w5_ukyHFfQwkBJ1dYTX_S7GBBp5JcGXZbb&s=FlU74dYJ9CsiPSN5wEZ5LrScMOWXuwB9QmIJRS5r-YI&e=> |
|
From: Marc C. <cul...@gm...> - 2025-08-18 12:47:46
|
On Mon, Aug 18, 2025 at 2:43 AM Erik Leunissen <el...@xs...> wrote: > On 8/17/25 16:18, Marc Culler wrote: > > Why not just install fossil on the old mac and build yourself? > > Because I remeber to have read somewhere that on a mac, one needs to > install > and wield XCode, which is something I have an aversion for. > There is no need to install XCode. You can install a minimal clang toolchain, called CommandLineTools by running the following command in your Terminal: xcode-select --install The xcode-select command normally selects the currently active toolchain. With the --install option it installs the current version of the CommandLineTools toolchain, which is stored in the directory /Library/Developer/CommandLineTools. The CommandLineTools does not include the auto-tools. You can install them from Homebrew or just build and install them yourself. - Marc |
26 messages has been excluded from this view by a project administrator.
