[Issue 4957] std.concurrency does not allow to pass Tid in struct fields
https://issues.dlang.org/show_bug.cgi?id=4957 ratchet freak changed: What|Removed |Added Keywords||pull --- Comment #4 from ratchet freak --- Pull request: https://github.com/D-Programming-Language/phobos/pull/3941 --
[Issue 15564] Bogus non local error messages
https://issues.dlang.org/show_bug.cgi?id=15564 Martin Nowak changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All --- Comment #4 from Martin Nowak --- cat > bug.d << CODE struct Foo { void foo(alias f)() { f(2); } } void test() { Foo foo; foo.foo!(function(int a) => 2 * a)(); // works w/ function foo.foo!(function(a) => 2 * a)(); // doesn't work w/ function template } CODE dmd -c bug bug.d(13): Error: template instance foo!(function (a) => 2 * a) cannot use local '__funcliteral1' as parameter to non-global template foo(alias f)() This was already not possible in 2.066.1. --
[Issue 15584] New: Security issue: symlink attack
https://issues.dlang.org/show_bug.cgi?id=15584 Issue ID: 15584 Summary: Security issue: symlink attack Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: cpic...@openmailbox.org There is a symlink attack because dmd overwrite the output file without checking whether it is a link or not. This can allow an attacker to overwrite any file accessible with the rights of the user that runs the compiler. For example .ssh/authorized_keys could be replaced in order to get remote access to the system. To reproduce: $ touch untouchable $ ln -s untouchable malicious $ echo 'import std.stdio; void main() {writeln("owned");}' > malicious.d $ dmd malicious.d $ ./untouchable owned --
[Issue 15584] Security issue: symlink attack
https://issues.dlang.org/show_bug.cgi?id=15584 --- Comment #1 from Cédric Picard --- For the record, I also checked for an attack through the generation of object files ($ ln -s untouchable malicious.o) but those aren't concerned. --
[Issue 15548] [Home] Interaction with the code box adds vertical space
https://issues.dlang.org/show_bug.cgi?id=15548 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from ag0ae...@gmail.com --- Fix should be live now. Closing as FIXED. --
[Issue 15548] [Home] Interaction with the code box adds vertical space
https://issues.dlang.org/show_bug.cgi?id=15548 --- Comment #8 from Bastiaan Veelo --- Confirmed. --
[Issue 15584] Security issue: symlink attack
https://issues.dlang.org/show_bug.cgi?id=15584 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #2 from ag0ae...@gmail.com --- I understand you're asking for dmd to replace the link, or maybe fail with an error message, instead of writing through the link. Not an unreasonable request, but is there really a strong expectation that programs don't write through symlinks, so that this is surprising behavior? After all, the victim has to set up the symlink. If the attacker could set it up, they could just overwrite untouchable directly. For what it's worth, gcc seems to behave like dmd: $ touch untouchable $ ln -s untouchable a.out $ cat > test.c << code #include int main() {printf("owned\n"); return 0;} code $ gcc test.c $ ./untouchable owned So maybe it's actually more expected that symlinks are followed, and not replaced. --
[Issue 15584] Security issue: symlink attack
https://issues.dlang.org/show_bug.cgi?id=15584 --- Comment #3 from Cédric Picard --- That may be true for gcc but I still think it is an issue. The classic setup isn't with two plain files, an attacker would give a huge project through a github repo for example and hide his link in layers of directories. An alert user may notice it but that's true of all attacks. On the other end a less wise user might just compile the project, in that case I'm definitive that getting ssh access for example is possible (I did it on my machine). Another argument in favor of simply removing symlinks is that this behaviour isn't consistent. Object files get their symlinks replaced, and if the file targetted by the symlink isn't empty the symlink gets removed too (which makes for a less dangerous vulnerability as we can create a file or change it if empty, but not change its content otherwise). This should be corrected. --
[Issue 15584] Security issue: symlink attack
https://issues.dlang.org/show_bug.cgi?id=15584 --- Comment #4 from ag0ae...@gmail.com --- Ok, I think I get it now. The point is that it's relatively easy for an attacker to slip a symlink through, compared to a shell command or a compiler argument. --
[Issue 15513] Memory Corruption with thread local objects
https://issues.dlang.org/show_bug.cgi?id=15513 --- Comment #3 from Puneet Goel --- Adding another test case. This time I could replicate the issue within a single thread. Testcase has been attached. This issue has also been discussed in the forum thread http://forum.dlang.org/thread/yjywwllcsslgotgrf...@forum.dlang.org --
[Issue 15513] Memory Corruption with thread local objects
https://issues.dlang.org/show_bug.cgi?id=15513 --- Comment #4 from Puneet Goel --- Created attachment 1577 --> https://issues.dlang.org/attachment.cgi?id=1577&action=edit Another testcase with just one thread --
[Issue 15573] -O -inline causes wrong code with idiv instruction
https://issues.dlang.org/show_bug.cgi?id=15573 --- Comment #24 from hst...@quickfur.ath.cx --- Maybe related?: https://issues.dlang.org/show_bug.cgi?id=10540 --
[Issue 15513] Memory Corruption with thread local objects
https://issues.dlang.org/show_bug.cgi?id=15513 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #5 from ag0ae...@gmail.com --- Reduced this some: foo.d: import std.stdio: writeln; import core.thread: Thread; void main() { writeln("Start frop from D"); frop(); } extern(C) void function() startup_routine = &initialize; extern(C) void initialize() { import core.runtime; Runtime.initialize; writeln("Start frop from C"); frop(); Runtime.terminate(); } void frop() { Thread bar = new Thread(&foo); bar.start(); bar.join(); } void foo() { proc(); new int; new int[10_000]; writeln(dash); } int[] dash; void proc () { dash.length = 8; dash[] = 0; } main.c: #include typedef void (*routine_t)(void); int main(int argc, char*argv[]) { void* dll = dlopen("./foo.so", RTLD_LAZY); routine_t* routine = (routine_t*)dlsym(dll, "startup_routine"); (*routine)(); } Compile and run: dmd foo.d && ./foo # change the path for the -L-R option according to your setup dmd -fPIC -shared -offoo.so -L-ldl -L-lphobos2 -L-R$HOME/d/dmd2.git/linux/lib64 foo.d gcc -m64 -fPIC main.c -ldl -o main ./main Output: Start frop from D [0, 0, 0, 0, 0, 0, 0, 0] Start frop from C [-1488654016, 32761, 37363216, 0, 0, 0, 0, 0] --
[Issue 15585] New: VRP incorrectly assumes that out-of-range dchar values don't exist
https://issues.dlang.org/show_bug.cgi?id=15585 Issue ID: 15585 Summary: VRP incorrectly assumes that out-of-range dchar values don't exist Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: thomas.bock...@gmail.com This issue doesn't currently have much in the way of visible symptoms, but it will as VRP gets smarter in other ways: https://github.com/D-Programming-Language/dmd/pull/5229 Fixing this was been pre-approved by Walter Bright on the forums (although there are other aspects of the above PR which are still under review): http://forum.dlang.org/post/oionrfexehapzicgp...@forum.dlang.org --
[Issue 15586] New: std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 Issue ID: 15586 Summary: std.utf.toUTF8() segfaults when fed an invalid dchar Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: thomas.bock...@gmail.com Repro: void main() { import std.utf : toUTF8; char[4] buf = void; auto b = toUTF8(buf, cast(dchar)0x11); import std.stdio; writeln(b); } Cause: toUTF8() asserts that invalid dchars just *don't exist*. It then proceeds to return *nothing at all* when fed one, which violates memory safety. Because of https://issues.dlang.org/show_bug.cgi?id=15585 the compiler may optimize away attempts to fix this entirely. --
[Issue 15573] -O -inline causes wrong code with idiv instruction
https://issues.dlang.org/show_bug.cgi?id=15573 --- Comment #25 from thomas.bock...@gmail.com --- The similar crashes I was getting with LDC turn out to be unrelated to this issue, despite the similar symptoms: https://issues.dlang.org/show_bug.cgi?id=15586 (It's a bug in Phobos, which I have already submitted a PR for.) --
[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 --- Comment #1 from thomas.bock...@gmail.com --- Fix for the Phobos bug: https://github.com/D-Programming-Language/phobos/pull/3943 Fix for the DMD bug: https://github.com/D-Programming-Language/dmd/pull/5229 --
[Issue 15587] New: Enable use of D keywords as identifiers when interfacing to C/C++
https://issues.dlang.org/show_bug.cgi?id=15587 Issue ID: 15587 Summary: Enable use of D keywords as identifiers when interfacing to C/C++ Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Consider: extern (C) int* with(); where delegate is a C function name. This, of course, fails because 'with' is a D keyword. A solution is: extern (C) int* with_(); and have the C/C++ name mangler remove any trailing _ from identifiers. The prefix version, _with, has problems because it would be impossible to have a C identifier named '_traits' or '_gshared'. --
[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++
https://issues.dlang.org/show_bug.cgi?id=15587 Walter Bright changed: What|Removed |Added Keywords||C++ --
[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx --- I don't understand something here. The in-contract of toUTF8 asserts that the dchar must be valid... but why does the assert not trigger at runtime (even in spite of not compiling with -release). This doesn't seem like a Phobos bug; it seems to be a bug in the compiler for "optimizing" away the assert just because it thinks that dchar's cannot have invalid values. --
[Issue 10378] Local imports hide local symbols
https://issues.dlang.org/show_bug.cgi?id=10378 --- Comment #20 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #19) > ah, i see, thank you. i really misread the suggesion. still, i like Kenji's > PR4915 more. ;-) i'd better see "shadowing error", so i can simply rename > symbols, and don't guess if there is conflict or not. Yes, thank you Timon for explaining better. The main reason I see local imports being useful is this: import somemodule; void foo() { onlyPlaceSomeModuleIsUsed() } Now, one can simply say "wait, somemodule isn't something everyone in the file needs, just foo. I'll move it inside" And then it breaks. I'd rather just see it work the same. All you are doing is saying who has access to somemodule's symbols, and avoid polluting the module namespace. --
[Issue 15585] VRP incorrectly assumes that out-of-range dchar values don't exist
https://issues.dlang.org/show_bug.cgi?id=15585 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx Severity|normal |critical --- Comment #1 from hst...@quickfur.ath.cx --- Actually, it *does* already cause a very visible, nasty problem: https://issues.dlang.org/show_bug.cgi?id=15586 Basically, by assuming that dchar can never have invalid values (no matter where the dchar came from), the compiler has basically turned all code containing `cast(dchar)` into undefined behaviour, because it will optimize out all character range checks (under its wrong assumption, none of the checks can ever fail, since dchar can't possibly have invalid values). This means string-vetting functions are basically turned to no-ops, and code that's supposed to throw exceptions or assert errors upon invalid dchar values will instead continue running wildly forward. This could mean that a function that's supposed to return something may actually return nothing, and the caller will get a garbage value instead (from whatever detritus is left in the return register when it was last modified). These problems are already showing up, even in non-release mode. I'm raising the severity of this bug. --
[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 --- Comment #3 from thomas.bock...@gmail.com --- > This doesn't seem like a Phobos bug; it seems to be a bug in the compiler for > "optimizing" away the assert just because it thinks that dchar's cannot have > invalid values. That's the compiler bug I linked to in the OP (15585). --
[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 --- Comment #4 from hst...@quickfur.ath.cx --- Keep in mind, though, that one *could* argue that casting an arbitrary value to dchar already constitutes UB, if dchars are deemed to only contain valid Unicode codepoints. If you need to work with incoming character data of unknown validity, you're probably better off working with uint (or uint[], ubyte[], etc.) instead, and only convert to dchar (string, etc.) after explicit validation. Generally, you probably shouldn't be casting stuff unless you know what you're doing and are ready to handle the consequences when things go wrong. --
[Issue 15586] std.utf.toUTF8() segfaults when fed an invalid dchar
https://issues.dlang.org/show_bug.cgi?id=15586 --- Comment #5 from thomas.bock...@gmail.com --- > Keep in mind, though, that one *could* argue that casting an arbitrary value > to dchar already constitutes UB This has already been settled. It's not: http://forum.dlang.org/post/oionrfexehapzicgp...@forum.dlang.org > Generally, you probably shouldn't be casting stuff unless you know what > you're doing and are ready to handle the consequences when things go wrong. 1) No casting is required to trigger this bug. I was just giving you a simplified test case. Here's a slightly less simple one, without any casts: import std.stdio; void main() { import std.utf : toUTF8; dchar a = dchar.max; a += 1; char[4] buf = void; auto b = toUTF8(buf, a); import std.stdio; writeln(b); } 2) "If you don't want segfaults, don't cast stuff" is an awful solution to a hard crash in @safe code. There is no good reason that casts of basic numeric or character types should cause this kind of failure. --
[Issue 14496] void initialization of member with indirections must not be @safe
https://issues.dlang.org/show_bug.cgi?id=14496 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 12822] Delegate .ptr assignment considered @safe
https://issues.dlang.org/show_bug.cgi?id=12822 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||accepts-invalid CC||hst...@quickfur.ath.cx --
[Issue 15507] Throwable.message() should be pure @safe
https://issues.dlang.org/show_bug.cgi?id=15507 Dicebot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Dicebot --- As actual addition has been reverted for now, the issue has become unapplicable. --