🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:55 gfldex left 00:57 gfldex joined 00:58 japhb left 01:00 japhb joined 01:06 japhb left, gfldex left, japhb joined, gfldex joined 01:13 japhb left 01:14 japhb joined 01:31 japhb left 01:33 japhb joined 02:04 guifa left 02:18 guifa joined 03:01 guifa left
ab5tract I'm once again a bit confused about the expectations of resources WRT distributions 05:28
if it's not cool to determine a path for these resources, I would expect that the anticipation is that resources would be written to temporary paths at every runtime 05:29
the behavior of OpenSSL seems like a security risk to me
as well as muddying the waters as to why we can't just access it at the path its installed to instead of installing into a semi-permanent path anyway 05:30
nine The one thing you absolutely must not assume is that the path you get at compilation time of your model will be the same as the path you'd get at runtime 07:10
07:14 sjm_ joined 07:22 [Tux] left 07:28 [Tux] joined 07:47 sjm_ left, sjm_ joined 07:52 sjm_ left 07:53 sjm_ joined
ab5tract right, that's a beg no-go. Maybe we could make a trait that can mark routines and methods as runtime only, and then .absolute in the wrong phase will produce a failure or die? 11:25
11:25 guifa joined
ab5tract Actually a sorry would be more appropriate 11:47
timo well, it'd be okay to access and use the path at compile time, it's just not okay to try to persist the path until run time and try to access it again 11:59
patrickb May I point a few eyes towards github.com/rakudo/rakudo/pull/5725 ? I believe it's ready to be merged. 12:26
ugexe ab5tract can you explain the security risk or is it just a feeling? The file is put into the users home directory so there should be no issue 12:57
12:58 guifa left
ugexe The whole sorry thing also ignores that it might not even be a file based resource 13:01
If something else is needed it needs to be designed and go through the whole problem solving rigmarole. It is not a simple problem with a simple answer and almost certain requires new api 13:02
13:22 sjm_ left, sjm_ joined 13:25 sjm_ left, sjm_ joined
ab5tract I would argue that it’s this resource-is-not-a-file (which feels very theoretical to me, do you have an example?) is what should have gotten the new API 13:54
How does one specify a non-file resource at this moment? 13:58
I’d have to look into how Windows handles access to temp files from other processes. If there is no protection, then using deterministic file paths would allow for other processes running under the user account to replace the OpenSSL DLL file with a nefarious one 13:59
nine linked to the category of exploit yesterday
ugexe CompUnit::Repository::* such as Tar or Github 14:07
in the case of tar there is an actual file, but the resource/modules/etc come from inside the tar file
timo did anyone try something like FatPacker yet?
ugexe with Github they get loaded by a socket or some such 14:08
ab5tract: nine linked to something that boiled down to using /tmp, which you pointed out isnt happening with openssl
on windows
if a malicious user can access files under a users home directory somewhere (which is apparently where $*TMPDIR is on windows by default) then even if we installed openssl dlls with the other raku files it would still be replaceable by said malicious user 14:10
hence why the issue there boils down to using /tmp
which is not necessarily the same thing as a "temporary directory" 14:11
timo there's also fun things like putting a symbolic link in the place before the process writes its thing to cause other files to be overwritten
ugexe does windows do symbolic links? for this specific openssl case we have the benefit of being restricted to windows
timo the raku file may be write-protected when stuff in $*TMPDIR wouldn't be
there are ntfs "junctions" which i hear is similar
but i never actually tried them myself 14:12
ugexe we can write protect a file we put in tmpdir as well
timo yes but with the caveat you mentioned before that if the "attacker process" has the same rights as our raku process it could just un-writeprotect it immediately?
the big issue with the /tmp is that /tmp is shared by all users, though with systemd it's trivial to give individual processes or groups of processes their very own private /tmp 14:13
ugexe again, not /tmp
timo yeah
i was mentioning it kind of as a contrast to the windows situation 14:14
ab5tract Windows is pretty broken at the user access control level
But yeah, I guess if it can access the temp files it can access the installed one 14:16
ugexe does windows come with a package manager by default yet that could be invoked to install openssl at build time in Build.rakumod? 14:17
timo if raku is installed to Program Files it has special protections and privileges
not aware of an installed-by-default thing apart from the MSI stuff which is not exactly that 14:18
i'm sure a dev with some actual deep windows knowledge could do some great things
ugexe winget?
i forget if it is turned on by default now or if some toggle needs to be switched 14:19
timo wowser
ugexe regardless, the pattern of installing an external library somewhere outside of the raku source files invoking the installation is not exactly uncommon 14:20
which is quite similar to what openssl does, although far more naive
timo nine: it looks like we will revert to not packaging precomped files in raku modules on debian just for now. not great, but it does at least prevent breakage, and we get to fix things after making sure that the packages at least don't get dropped from debian 15:09
[Tux] Rakudo v2025.04-8-ge5c74d0ac (v6.d) on MoarVM 2025.04-5-gc99d245d5
csv-ip5xs0.259 - 0.263
csv-ip5xs-201.071 - 1.081
csv-parser1.117 - 1.120
csv-test-xs-200.114 - 0.118
test1.830 - 1.842
test-t0.413 - 0.422
test-t --race0.271 - 0.277
test-t-204.942 - 5.136
test-t-20 --race1.239 - 1.279
 15:19
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
nine ugexe: the $*TMPDIR usage was in Resource::Wrangler, not OpenSSL 15:58
timo: what's the problem on Debian in the first place? 15:59
timo it's a whole clusterfuck involving me not using my eyes i guess 16:00
ugexe $*TMPDIR is used in OpenSSL as well and probably what Resource::Wrangler was emulating. however, openssl only uses $*TMPDIR on windows (which is fine)
17:17 sjm_ left, sjm_ joined 17:22 sjm__ joined, sjm_ left 17:26 sjm_ joined 17:27 sjm__ left 17:50 finanalyst joined
patrickb timo: rakubrew is using fatpack 17:52
18:03 finanalyst left
timo but that's perl5's fat packer right? 19:12
20:31 [Coke] left
patrickb yes 20:59
timo right, i was wondering particularly if anyone made a fat pack equivalent for raku yet 22:04
ugexe CompUnit::Repository::Tar is sort of along those lines 22:09
Could probably hack something that takes a script, puts all its source and dependencies into a tar file, save that binary data in the new fat packed generated script, and then feed that data into the C::R::Tar-like thing 22:11
gonna be slow without precompilation though 22:12
22:27 [Coke] joined 22:52 guifa joined 23:10 japhb left 23:17 japhb joined 23:42 japhb left 23:43 japhb joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!