On Thursday, 31 July 2025 at 21:34:36 UTC, H. S. Teoh wrote:
> This tone is uncalled for.  OP is specifically pointing the issue with passing NUL-containing strings to underlying OS calls.  T

No, OP isn't doing that. OP is fishing and it's obvious:
1. No problematic example that is specific to D
2. Generic source that concerns multiple languages but doesn't cite D
3. Immediately pulled out an "examplary" python program and touting the superiority of that language.

Any reasonable person should therefore conclude that it's a generalizing statement that was made without prior knowledge about D and that the OP didn't make any substantial testing to prove the problem. They hoped instead that it would be true. Therefore, you are a fish and you just took the bait.

On Thursday, 31 July 2025 at 21:35:50 UTC, Alex Bryan wrote:
> It is best NOT to be rude and nasty, but if you are, you should at least understand the technical argument
I understand the entire argument of OP. OP is not arguing anything. They are fishing. They know nothing about D. If you don't find such individuals problematic, then perhaps I should start polluting your repos with imaginary problems. I'm bound to guess one right. The solution to lazy, no research, generic, python supremacy horseshit is to reply in a way that scares them away. Like the telemarketer at the door, you slam in it in their face with a big "fuck off my lawn". If they were genuine, they wouldn't have done what they did, especially not in the way they did it. They were fishing and they hooked on a fish alright...

On 01/08/2025 11:14 AM, Doigt wrote:
> On Thursday, 31 July 2025 at 21:34:36 UTC, H. S. Teoh wrote:
>> This tone is uncalled for.  OP is specifically pointing the issue with passing NUL-containing strings to underlying OS calls.  T
> 
> No, OP isn't doing that. OP is fishing and it's obvious:
> 1. No problematic example that is specific to D
> 2. Generic source that concerns multiple languages but doesn't cite D
> 3. Immediately pulled out an "examplary" python program and touting the superiority of that language.
> 
> Any reasonable person should therefore conclude that it's a generalizing statement that was made without prior knowledge about D and that the OP didn't make any substantial testing to prove the problem. They hoped instead that it would be true. Therefore, you are a fish and you just took the bait.

This is a valid security problem with std.stdio and std.file.

They do not have to produce an example showing that bad behavior exists on our end, this is documented as being possible on the system API's which we wrap without validation.

https://github.com/dlang/phobos/
blob/2d8ae67b396f5cc5f4633695c1c5ac67d2bf448e/std/stdio.d#L432

On Thursday, 31 July 2025 at 23:14:46 UTC, Doigt wrote:
> On Thursday, 31 July 2025 at 21:34:36 UTC, H. S. Teoh wrote:
>> This tone is uncalled for.  OP is specifically pointing the issue with passing NUL-containing strings to underlying OS calls.  T
>
> No, OP isn't doing that. OP is fishing and it's obvious:
> 1. No problematic example that is specific to D
> 2. Generic source that concerns multiple languages but doesn't cite D
> 3. Immediately pulled out an "examplary" python program and touting the superiority of that language.
>
> Any reasonable person should therefore conclude that it's a generalizing statement that was made without prior knowledge about D and that the OP didn't make any substantial testing to prove the problem. They hoped instead that it would be true. Therefore, you are a fish and you just took the bait.

I bet op is a enterprise-grade security researcher; I suggest light mocking when they claim rust is the future or @safe/immutable is very important for game dev

On Thursday, 31 July 2025 at 21:55:03 UTC, kdevel wrote:
> On Thursday, 31 July 2025 at 21:25:44 UTC, Doigt wrote:
>> [...]
>> Do you actually have a source or an example program that D actually does anything with the null terminator
>
> I did not argue that D "does" something "with the null terminator".
> D like perl or Ada
and this is my entire problem with your entire argument. You are generalizing based on preconceived notions. You are guessing. You aren't actually informed about D. You don't really care what D does and how we program in D. You immediately tout python's superiority in our faces. You impose a solution just because python does it. What about trying out D for real? Have you programmed in D even once? Do you know what is the stance of the community on exceptions? Do you know how we usually (do or don't) handle the null terminator? No, you don't. You're fishing and you have two big ones on your line, but that doesn't mean I'll bite.

Like barging into someone's home suddenly without ever meeting them before and demanding they do things for you even though you don't even care that they do it.

On Thu, Jul 31, 2025 at 10:27:56PM +0000, monkyyy via Digitalmars-d wrote:
> On Thursday, 31 July 2025 at 21:47:24 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
> > This is quite a good example of why for PhobosV3 I want us to go through a FilePath abstraction, rather than accepting random strings for file names.
> 
> whats wrong with just changing toStringz? I dont understand the threat profile imagined by the infinitely wise cve org; but you could make toStringz:
> 
> a) shorten it to the first null char
[...]

This is precisely what it currently does, and where the problem is. Consider: you have user input specifying a filename, and your code checks to make sure it doesn't overwrite a file it's not supposed to. As a contrived example, say you prohibit "/etc/passwd" as a filename. Now what happens when the user inputs "/etc/passwd\0ha_you_missed_me" as filename?  The OS considers the NUL as the end of the filename, so your user gets access to "/etc/passwd" after all.

Another example: maybe you have a database management program and your user specifies a filename to save the database, and you keep an AA of previously-used names which you check, so that the user doesn't stomp over another user's database file.  Now consider what happens if user A inputs "database\01.db" and user B inputs "database\02.db".  The OS considers the NUL as the end of the filename, so user A's file is actually "database", and so is user B's file, so user B can now overwrite user A's data.

These are just some mild cases.  I'm pretty sure if you think hard enough, you'll be able to come up with something that will open a security hole by exploiting the fact that what the D code thinks is the filename is different from what the OS thinks is the filename.


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Thursday, 31 July 2025 at 23:20:28 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 01/08/2025 11:14 AM, Doigt wrote:
>> On Thursday, 31 July 2025 at 21:34:36 UTC, H. S. Teoh wrote:
>>> This tone is uncalled for.  OP is specifically pointing the issue with passing NUL-containing strings to underlying OS calls.  T
>> 
>> No, OP isn't doing that. OP is fishing and it's obvious:
>> 1. No problematic example that is specific to D
>> 2. Generic source that concerns multiple languages but doesn't cite D
>> 3. Immediately pulled out an "examplary" python program and touting the superiority of that language.
>> 
>> Any reasonable person should therefore conclude that it's a generalizing statement that was made without prior knowledge about D and that the OP didn't make any substantial testing to prove the problem. They hoped instead that it would be true. Therefore, you are a fish and you just took the bait.
>
> This is a valid security problem with std.stdio and std.file.
>
> They do not have to produce an example showing that bad behavior exists on our end, this is documented as being possible on the system API's which we wrap without validation.
>
> https://github.com/dlang/phobos/
> blob/2d8ae67b396f5cc5f4633695c1c5ac67d2bf448e/std/stdio.d#L432

you provided the proof for them and you are correct in pointing it out that it exists on our end. But if their guess had been wrong, it would have all wasted our time and energy. This kind of fishing without proof shouldn't be acceptable

On Thursday, 31 July 2025 at 23:27:42 UTC, H. S. Teoh wrote:
> On Thu, Jul 31, 2025 at 10:27:56PM +0000, monkyyy via Digitalmars-d wrote:
>> On Thursday, 31 July 2025 at 21:47:24 UTC, Richard (Rikki) Andrew Cattermole
>> wrote:
>> > This is quite a good example of why for PhobosV3 I want us to go through a FilePath abstraction, rather than accepting random strings for file names.
>> 
>> whats wrong with just changing toStringz? I dont understand the threat profile imagined by the infinitely wise cve org; but you could make toStringz:
>> 
>> a) shorten it to the first null char
> [...]
>
> This is precisely what it currently does, and where the problem is. Consider: you have user input specifying a filename, and your code checks to make sure it doesn't overwrite a file it's not supposed to. As a contrived example, say you prohibit "/etc/passwd" as a filename. Now what happens when the user inputs "/etc/passwd\0ha_you_missed_me" as filename?  The OS considers the NUL as the end of the filename, so your user gets access to "/etc/passwd" after all.
>
> Another example: maybe you have a database management program and your user specifies a filename to save the database, and you keep an AA of previously-used names which you check, so that the user doesn't stomp over another user's database file.  Now consider what happens if user A inputs "database\01.db" and user B inputs "database\02.db".  The OS considers the NUL as the end of the filename, so user A's file is actually "database", and so is user B's file, so user B can now overwrite user A's data.
>
> These are just some mild cases.  I'm pretty sure if you think hard enough, you'll be able to come up with something that will open a security hole by exploiting the fact that what the D code thinks is the filename is different from what the OS thinks is the filename.
>
>
> T

~~I think these are extremely contrived, passwd is the os's responsibly and I expect all oses have it behind root permissions; also backups~~

swapping toStringz to option 2 then?

I think adr's FilePath may come from stealing code from rikki, and in thoery what rikki is suggesting is I call `File(FilePath("foo"))` I didnt like figuring it out; I wont actually store a filepath, I will write string then do whatever the error messages and instinct says will make the code I wrote compile

If `"passwd\0hi".toStringz == &"passwd__NULL__DONT_DO_THAThi"[0]` it wont match `passwd`; whats the `file(filepath)` abstraction gaining over option 2 or 3

On Thursday, 31 July 2025 at 20:45:14 UTC, kdevel wrote:
> Some python code:
>
>    #!/usr/bin/python
>
>    def myfun (filename):
>       open (filename, 'w')
>
>    myfun ("a\0c")
>
> which when executed behaves in an exemplary manner:
>
>    Traceback (most recent call last):
>      File "./test.py", line 6, in <module>
>        myfun ("a\0c")
>      File "./test.py", line 4, in myfun
>        open (filename, 'w')
>    TypeError: file() argument 1 must be encoded string without null
>    bytes, not str
>
> Other languages like D, perl or even Ada seem to let the embedded NUL
> character silently truncate the filename. This poses a considerable
> risk when the input to std.file functions is not controlled by the
> program author [1]. E.g.
>
>    rmdirRecurse ("/\0/home/user/subdir");
>
> [1] https://cwe.mitre.org/data/definitions/158.html

Rikki pointed out to me that I was blind. I apologize for my tone. You did provide that code that proved your assertion. I was wrong to say what I said and I take back everything I said. I will now retire myself from this discussion.