[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16588

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16588

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16588

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||thecybersha...@gmail.com
 Resolution|FIXED   |---

--- Comment #5 from Vladimir Panteleev  ---
Reverted by https://github.com/dlang/phobos/pull/5384

--

[Issue 17264] [REG2.073] uniq fails with const elements

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17264

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/113502af744fb82d68e8f51fd73831b628dcc1eb
std.algorithm.iteration: Add test for issue 17264

Fixes Issue 17264 - [REG2.073] uniq fails with const elements

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #7 from Cédric Picard  ---
(In reply to Vladimir Panteleev from comment #5)
> (In reply to Cédric Picard from comment #4)
> > Not at all, while what you describe is the most common case there are many
> > things that are possible through XSS that do not target the current domain.
> 
> Could you provide some examples which would be applicable to us?

Well, I'm not sure this is the right place to talk about that, but it's an XSS,
it can do anything JS in a webpage can, so making external calls to APIs,
executing an IRC bot, delivering malware...

With some timing tricks it is also possible to scan the user's network for
available ports on local and nearby computers.

With a browser bug such as
https://www.brokenbrowser.com/sop-bypass-uxss-stealing-credentials-pretty-fast/
(taking one from today, those are pretty common) it's possible to bypass any
security tying the code to the local domain. From there you can get data from
other pages, read and send local files etc.

Anything a normal malicious webpage can do, this is in no way specific to D.

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16746

--- Comment #13 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #12)
> Sounds really good, but AFAIK this is still in the far future...
> GDC supports writing depfiles properly, and having this feature in DMD would
> enable it for DMD and LDC at the same time, making depfiles work for all D
> compilers.

That's true.

> Usually in distributions we package just the minimal amount of things
> necessary to compile a certain leaf package (e.g. all the stuff one needs to
> compile Vibe.d/Tilix/...) and more is added when another package requires
> the feature.

That makes sense if you treat D purely as a dependency, but I think it's worth
looking at it as a software application package as well. rdmd is mentioned in
TDPL, so it is essentially part of D. This is why I'm uneasy about the idea of
splitting up the tools that dlang.org ships together.

> At the moment, nothing uses rdmd, and adding it would mean someone would
> need to maintain the package over the lifetime of the distro release.

Why a separate package? Why not ship it with dmd? Is it just because it's
useful not just for dmd, but also ldc/gdc? If so, why not have a dtools package
like Arch Linux, which includes rdmd, dustmite, ddemangle, etc.?

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16746

--- Comment #12 from Matthias Klumpp  ---
(In reply to Vladimir Panteleev from comment #11)
> (In reply to Matthias Klumpp from comment #10)
> > Because the wrapper is not available everywhere, and going through a wrapper
> > in order to fix a missing thing in dmd is just a workaround. DMD(FE) should
> > be able to do this natively.
> > When adding support to Meson/CMake/Automake/Makefiles, telling users that
> > they need the compiler but also this other tool which - in the Meson world -
> > has the sole purpose of supplying a missing functionality in DMD is pretty
> > cumbersome. It's a workaround, but no real solution to the issue.
> 
> I'm not sure about referring to a requested feature as "missing
> functionality", but thanks for the clarification.
> 
> Regardless, we will hopefully one day have rdmd as part of dmd itself, or
> use the compiler as a library, so duplicating functionality in both dmd and
> rdmd right now does not look very appealing; until then, you may want to
> look into more pragmatic solutions, such as using rdmd.

Sounds really good, but AFAIK this is still in the far future...
GDC supports writing depfiles properly, and having this feature in DMD would
enable it for DMD and LDC at the same time, making depfiles work for all D
compilers.

> > At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
> > don't ehip rdmd at all, which makes demanding it just to work around this
> > bug not worthwile anyway.
> 
> I think rdmd should be shipped in the same package as dmd. This is how the
> binary packages from dlang.org for all platforms are. Picking and choosing
> which utilities the distribution considers useful will inevitably lead to
> confusion and a poorer user experience.

Usually in distributions we package just the minimal amount of things necessary
to compile a certain leaf package (e.g. all the stuff one needs to compile
Vibe.d/Tilix/...) and more is added when another package requires the feature.
At the moment, nothing uses rdmd, and adding it would mean someone would need
to maintain the package over the lifetime of the distro release.

Personally I try to avoid taking on new packages on a "could be useful" basis,
because the time I can invest in maintenance is limited, and it's better to
have fewer well-supported packages than lots of them which are poorly
maintained.
(Team maintenance helps a lot with this, but only if the team is actually big
enough, which isn't the case in with D yet).

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16746

--- Comment #11 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #10)
> Because the wrapper is not available everywhere, and going through a wrapper
> in order to fix a missing thing in dmd is just a workaround. DMD(FE) should
> be able to do this natively.
> When adding support to Meson/CMake/Automake/Makefiles, telling users that
> they need the compiler but also this other tool which - in the Meson world -
> has the sole purpose of supplying a missing functionality in DMD is pretty
> cumbersome. It's a workaround, but no real solution to the issue.

I'm not sure about referring to a requested feature as "missing functionality",
but thanks for the clarification.

Regardless, we will hopefully one day have rdmd as part of dmd itself, or use
the compiler as a library, so duplicating functionality in both dmd and rdmd
right now does not look very appealing; until then, you may want to look into
more pragmatic solutions, such as using rdmd.

> At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
> don't ehip rdmd at all, which makes demanding it just to work around this
> bug not worthwile anyway.

I think rdmd should be shipped in the same package as dmd. This is how the
binary packages from dlang.org for all platforms are. Picking and choosing
which utilities the distribution considers useful will inevitably lead to
confusion and a poorer user experience.

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16746

--- Comment #10 from Matthias Klumpp  ---
(In reply to Vladimir Panteleev from comment #9)
> (In reply to Matthias Klumpp from comment #8)
> > Yes, it doesn't support all command-line flags one would use with ldc, gdc
> > or dmd.
> 
> rdmd simply forwards flags it doesn't recognize to the compiler.
> 
> > Any wrapper is not an option.
> 
> Why?

Because the wrapper is not available everywhere, and going through a wrapper in
order to fix a missing thing in dmd is just a workaround. DMD(FE) should be
able to do this natively.
When adding support to Meson/CMake/Automake/Makefiles, telling users that they
need the compiler but also this other tool which - in the Meson world - has the
sole purpose of supplying a missing functionality in DMD is pretty cumbersome.
It's a workaround, but no real solution to the issue.

At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
don't ehip rdmd at all, which makes demanding it just to work around this bug
not worthwile anyway.

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Vladimir Panteleev  ---
https://github.com/dlang/dlang.org/pull/1649

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Cédric Picard from comment #4)
> Not at all, while what you describe is the most common case there are many
> things that are possible through XSS that do not target the current domain.

Could you provide some examples which would be applicable to us?

> Given how DDOC
> works I don't think it is fixable at all if not dropping all support for
> inlined html which I didn't realize was an issue at the time.
> 
> I suppose it's a won't fix, at least a bug report will be there for the next
> person to discover this.

Yep, I think documenting this is the immediate fix.

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #4 from Cédric Picard  ---
(In reply to Vladimir Panteleev from comment #3)
> As I understand, this only matters from a security standpoint when DDoc
> output is placed on the same domain as some dynamic content being targeted.

Not at all, while what you describe is the most common case there are many
things that are possible through XSS that do not target the current domain.
Also bugs in browsers are a common thing.

> > Limiting the use to some tags would help the usability issue but not the
> > security one.
> 
> As I understand, there is no usability issue here because it's working as
> designed. Use $(LT) and $(GT) (or  and  if you don't care about any
> output formats other than HTML) for < and >.

Well, I first discovered the thing because I hit it. But sure, if it's as
designed, no comment here.

> Anyway, limiting the use of some tags probably wouldn't work because the
> document template is likely to have some macros involving script tags (or
> allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG)
> macro). Fixing it from this angle would be much more complicated.

Indeed, also there are much more subtle XSSs than

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Cédric Picard from comment #2)
> I was not aware that it is so by design. However if it is a design decision
> I believe the security consequences should be made very explicit and clear
> in DDOC's documentation so that people avoid distributing third-party
> projects' documentation or do it very carefuly.

As I understand, this only matters from a security standpoint when DDoc output
is placed on the same domain as some dynamic content being targeted.

> Limiting the use to some tags would help the usability issue but not the
> security one.

As I understand, there is no usability issue here because it's working as
designed. Use $(LT) and $(GT) (or  and  if you don't care about any
output formats other than HTML) for < and >.

Anyway, limiting the use of some tags probably wouldn't work because the
document template is likely to have some macros involving script tags (or
allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG) macro).
Fixing it from this angle would be much more complicated.

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #2 from Cédric Picard  ---
I was not aware that it is so by design. However if it is a design decision I
believe the security consequences should be made very explicit and clear in
DDOC's documentation so that people avoid distributing third-party projects'
documentation or do it very carefuly.

Limiting the use to some tags would help the usability issue but not the
security one.

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Hmm... DDoc allows embedding HTML "by design", so this is not a bug. 

It might be an issue for websites which display documentation of third-party
packages though.

Perhaps it would make sense to forbid certain HTML tags in .d files (i.e.
inline documentation comments and the "Macros" section), while still allowing
them in macro definitions in .ddoc files.

--

[Issue 17391] New: SECURITY: XSS through DDOC comments

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

  Issue ID: 17391
   Summary: SECURITY: XSS through DDOC comments
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

DDOC comments are not escaped and this results in a XSS vulnerability.

Proof of concept:

test.d:

/// alert(2)
void f() {
return;
}

$ dmd -D test.d
$ firefox test.html  -> an alert box appears

The security issue is clear although it requires manipulating the user to
compile and display malicious comments. But as compiling the documentation is
something many do before thoroughly reading the code it's still a valid
security issue.

Also, aside from that, it breaks valid documentation so there's a usability
issue as well.

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16746

--- Comment #9 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #8)
> Yes, it doesn't support all command-line flags one would use with ldc, gdc
> or dmd.

rdmd simply forwards flags it doesn't recognize to the compiler.

> Any wrapper is not an option.

Why?

--

[Issue 14639] Assigning init value to struct uses stack, causing segfault

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14639

--- Comment #3 from Walter Bright  ---
The code:

biggy = Biggy.init;

gets rewritten to be:

biggy = Biggy([0LU, ...]);

which is a construction. The postblit caused an opAssign() to be created, and
the expression is further rewritten to:

biggy.opAssign(Biggy([0LU, ...]));

which blows up the parameter stack because Biggy([0LU, ...]) is too big for it.
The operation is not disabled because it gets constructed in place - a copy is
not being made.

A possible compiler fix is to figure out that the generated opAssign is trivial
and can be replaced with a bit copy. The code in opover.d:

if (sd && !sd.hasIdentityAssign)
{
/* This is bitwise struct assignment. */
return;
}

can be modified to test for triviality of identity assign, and use a bitwise
copy.

--

[Issue 17390] New: Pass flags to linker driver without -Xlinker

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17390

  Issue ID: 17390
   Summary: Pass flags to linker driver without -Xlinker
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: adr...@matoga.info

There's an open PR to LDC [1] to allow passing options to the linker driver
without -Xlinker on non-Windows platforms.
This is required e.g. for flags like --sysroot=path [2] or flags from
pkg-config [3] to work as expected.

The PR [1] adds option '-Xcc OPT', which passes OPT directly to the linker
driver (e.g. gcc or clang) without prepending it with -Xlinker. The global
order of flags passed via '-Xcc' and '-L' is preserved, and libraries requested
via pragma(lib) are appended after those flags.

The choice of '-Xcc' was motivated by clang's convention [4].

A similar feature would probably be useful also for DMD users. Since '-Xcc'
doesn't look consistent with current use of '-X' in DMD, DMD probably should
use a different switch for it.

W.r.t. order of linker (or linker driver) flags, there're a few related DMD
issues [5].

[1] https://github.com/ldc-developers/ldc/pull/2104
[2] https://github.com/ldc-developers/ldc/issues/2093
[3] https://github.com/ldc-developers/ldc/issues/1700
[4] https://github.com/ldc-developers/ldc/issues/2093#issuecomment-299707520
[5] https://issues.dlang.org/show_bug.cgi?id=15574
[6] https://issues.dlang.org/show_bug.cgi?id=15531
[7] https://issues.dlang.org/show_bug.cgi?id=7044

--

[Issue 17389] New: std.traits.hasNested fails for class with member of same type

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17389

  Issue ID: 17389
   Summary: std.traits.hasNested fails for class with member of
same type
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

static class A
{
A a;
}
static assert(!hasNested!A);

hasNested fails to compile. Fix included in this PR:

https://github.com/dlang/phobos/pull/5379

--

[Issue 14639] Assigning init value to struct uses stack, causing segfault

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14639

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6766

--

[Issue 14639] Assigning init value to struct uses stack, causing segfault

2017-05-10 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14639

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
What's happening is the existence of the postblit, even though disabled, causes
the compiler to do the assignment by calling opAssign, where the argument is
passed by value. Passing by value means pushing it to the stack.

--