[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. --
