[Issue 16510] Request: RSA digital signature validation in phobos

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16510

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--- Comment #4 from Carsten Blüggel  ---
I'm replying to this and deliberately not to
https://issues.dlang.org/show_bug.cgi?id=17958, because this is more specific:
RSA digital signature validation

This operation is quite easy to implement and there are no security concerns I
can see here; all it requires are publicly available information: The digital
signature, the public RSA key, the plain message that was signed, some
math/en-/decoding operations applied [https://tools.ietf.org/html/rfc8017], a
base64 decoder and digest functions (present in phobos already) and a
simplified ASN1-decoder (for DigestInfo; no full-fledged one required for this
case). If there are plans to incorporate some more crypto in phobos, I will
gladly contribute/share implementations, some is already on
https://github.com/carblue, a lot still on my ssd.

All of the discussion in
https://forum.dlang.org/thread/osnema$d5s$1...@digitalmars.com is pointless
referring to this one operation "RSA digital signature validation", though the
discussion is absolutely valid and great care must be applied (leave it to
experts!) concerning cryptography in general (i.e. when e.g. secret/private key
material is involved; that's why the general case of 
https://issues.dlang.org/show_bug.cgi?id=17958 is different and not really a
duplicate of this).

My take on aforementioned security discussion is also differing in that I would
rely on specialized hardware like smart cards or USB tokens only (both based on
small crypto chips) to store secrets and perform security related operations,
and use a widely-used, platform-independant API like PKCS#11/Cryptoki, now
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html,
thus there would be no need to implement AES (precisely a frame function
calling e.g. intel's dedicated asm instructions), RSA and alike: An affordable
USB crypto token (17-50 €; smart cards even less) has all that implemented
already. The only dependency (for some operations only) would be on a library
that implements PKCS#11 API, either specific for the hardware from it's vendor
or the multi-platform one from the OpenSC project, which supports a lot of
smart cards/USB tokens, itself depending on openssl.
Thus the Crypto interface in phobos would be a smart D wrapper around the
PKCS#11 API + some code for cases when there is no secret/private key involved
and no PKCS#11 library support available or necessary like for "RSA digital
signature validation".
For the sake of fairness, it should be mentioned, that even some crypto chips
aren't abolutely secure, free of vulnerability notes like
https://www.kb.cert.org/vuls/id/307015. But they are the best choice I can
think of, far better than file based secrets.

I assume You are the donor, referred to in
https://forum.dlang.org/thread/osnema$d5s$1...@digitalmars.com. Then I propose,
You ask Andrei Alexandrescu about his and Walter's plans concerning more crypto
in phobos, because what I read from the discussion (not all as it got somewhat
lost in prevalent dll discussion) was prevalently expressing fear to touch
crypto at all. It's not justified to be scary here following the route I
proposed. In principle, even the "RSA digital signature validation" can
completely be done by the crypto chip, but as this is a slow bottle neck for
large messages to be hashed, it's usually done by the PKCS#11 library or future
D code.

'Bindings' to the PKCS#11 API are available.
There is also the expertise of Cryptography in D - Amaury Séchet | DConf2017
https://www.youtube.com/watch?v=CoibdYFM53U

--

[Issue 18294] std.path.dirName needs better documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18294

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
(In reply to bachmeil from comment #0)
> std.path.dirName has no examples. The documentation is incomplete, because
> the function can yield surprising output.
> 
> std.path.dirName("foo/bar/baz") returns "foo/bar".
> std.path.dirName("foo/bar/baz/") also return "foo/bar", even though "baz/"
> is clearly a directory.
> 
> The only documentation is "Returns the directory part of a path." It should
> be clarified that the end of the path is always assumed to be a file, even
> if it ends with "/".

Actually, that particular result is because dirName gives you the parent
directory, not because it's assuming that the end of the path is a file.
Whether the end of the path is a directory or file or whatever is irrelevant
(and to an extent has to be, because it doesn't check whether the path even
exists, let alone what it points at). But really, the documentation should say
that it gives the parent directory of the argument rather than the "directory
part" of the argument.

--

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18296

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

https://github.com/dlang/druntime/commit/2d45fcbbd7a734bb6ecf8ba3d60897e8fefc4d44
use more specific workaround for Issue 18296

--

[Issue 18267] Linker errors compiling std_data_json dub package with dmd 2.078.0

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18267

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|major   |regression

--

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18296

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
FYI the discussion happens at this PR:
https://github.com/dlang/druntime/pull/2048

--

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18296

--- Comment #1 from Martin Nowak  ---
Only occurs with PIC enabled, guess this happens as a result of
https://github.com/dlang/dmd/pull/7654 whereby coverage symbols no longer have
local linkage.

--

[Issue 14767] Support CTFE of BigInt under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14767

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f2c5ee3bf17707ea16c2d7c269b3537a46d11032
fix issue 14767 - Support CTFE of BigInt under x86

https://github.com/dlang/phobos/commit/3784831e30f707d3c1411a639540e2bd2b3e241c
Merge pull request #6029 from BBasile/issue-14767

fix issue 14767 - Support CTFE of BigInt under x86
merged-on-behalf-of: Jack Stouffer 

--

[Issue 14767] Support CTFE of BigInt under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14767

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18296] New: [Reg2.078.1] invalid code with coverage and copy construction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18296

  Issue ID: 18296
   Summary: [Reg2.078.1] invalid code with coverage and copy
construction
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
alias AliasSeq(Args...) = Args;

struct Duration
{
this(long hnsecs)
{
_hnsecs = hnsecs;
}


long _hnsecs;
}

void main()
{
foreach(U; AliasSeq!(Duration, const Duration))
{
const Duration t = 42;
U u = t;
assert(t._hnsecs == u._hnsecs);
}
}
CODE

dmd -cov -run bug.d

--

[Issue 18295] [Scope][dip1000] `scope class` check too conservative under -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18295

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull, rejects-valid

--

[Issue 18295] [Scope][dip1000] `scope class` check too conservative under -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18295

--- Comment #1 from Mike Franklin  ---
Potential Fix: https://github.com/dlang/dmd/pull/7771

--

[Issue 18295] New: [Scope][dip1000] `scope class` check too conservative under -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18295

  Issue ID: 18295
   Summary: [Scope][dip1000] `scope class` check too conservative
under -dip1000
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slavo5...@yahoo.com

In practice, the following two examples are no different:

Example 1: Compile with -dip1000

scope class C { int i; }// Notice the use of `scope` here

C increment(C c)// Error: functions cannot return scope C
{
c.i++;
return c;
}

void main()
{
scope C c = new C();
c.increment();
}

Example 2: Compile with -dip1000

class C { int i; }   // Notice the absence of `scope` here

C increment(C c) // OK: no error
{
c.i++;
return c;
}

void main()
{
scope C c = new C();
c.increment();
}

So, I argue that with the introduction of the -dip1000 compiler switch it is no
longer necessary conservatively check the function declaration for `scope
class`es.  Rather a `scope class` should simply require variable instantiations
to be attributed with `scope`, and let -dip1000 do the rest.

--

[Issue 18294] New: std.path.dirName needs better documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18294

  Issue ID: 18294
   Summary: std.path.dirName needs better documentation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: bachm...@yahoo.com

std.path.dirName has no examples. The documentation is incomplete, because the
function can yield surprising output.

std.path.dirName("foo/bar/baz") returns "foo/bar".
std.path.dirName("foo/bar/baz/") also return "foo/bar", even though "baz/" is
clearly a directory.

The only documentation is "Returns the directory part of a path." It should be
clarified that the end of the path is always assumed to be a file, even if it
ends with "/".

--

[Issue 18269] Inconsistent string representation of delegate @system attribute

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18269

--- Comment #2 from hst...@quickfur.ath.cx ---
Reduced further:
---
void one(T)(T t, size_t ln = 0)
{
pragma(msg, "one: ", T.stringof);
two(t);
}

void two(T)(T t)
{
pragma(msg, "two: ", T.stringof);
}

alias T = void delegate();

void main()
{
void func() @system { __gshared int x; ++x; throw new Exception(""); }
one();
}
---

Commenting out the `alias T` line makes the problem go away.

Current investigation seems to be pointing to an ambiguity in the string table.
Still investigating further to narrow the problem down further.

--

[Issue 18252] [Reg 2.078] comparison of arrays of associative arrays no longer compiles

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Martin Nowak  ---
https://github.com/dlang/druntime/pull/2058

--

[Issue 18252] [Reg 2.078] comparison of arrays of associative arrays no longer compiles

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|no property 'tupleof' for   |[Reg 2.078] comparison of
   |type 'string[int]'  |arrays of associative
   ||arrays no longer compiles

--- Comment #3 from Martin Nowak  ---
cat > bug.d << CODE
void foo()
{
string[int][] aa1, aa2;
auto r = aa1 == aa2;
}
CODE

Digger says: https://github.com/dlang/dmd/pull/7225

--

[Issue 18293] bugzilla search does not work (misses word that's right there in issue title)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18293

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from ag0ae...@gmail.com ---
On the results page, above the table, you can see that the quick search only
looks for open issues ("Status: UNCONFIRMED, NEW, ASSIGNED, REOPENED"). 16640
has already been fixed, so you have to include the RESOLVED status when
searching.

You can do that by clicking the "Search" link to the left of the quick search
text input field. There, select "Status: All". Then you get these results which
include 16640:

https://issues.dlang.org/buglist.cgi?bug_status=__all__=__FILE_FULL_PATH___id=219081=Importance_format=specific

Closing as invalid.

--

[Issue 18293] New: bugzilla search does not work (misses word that's right there in issue title)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18293

  Issue ID: 18293
   Summary: bugzilla search does not work (misses word that's
right there in issue title)
   Product: D
   Version: D2
  Hardware: All
OS: Mac OS X
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

I was doing a search on `__FILE_FULL_PATH__`:

https://issues.dlang.org/buglist.cgi?quicksearch=%22__FILE_FULL_PATH__%22_id=219067


it returned:

17398   D   dmd nob...@puremagic.comNEW --- Partial
template struct instantiation with __FILE__ leading to link error

it missed:

https://issues.dlang.org/show_bug.cgi?id=16640

Issue 16640 - void fun(string file=__FILE_FULL_PATH__) returns relative path

which has the queried string `__FILE_FULL_PATH__` right there in the title

--

[Issue 18280] std.algorithm.comparison.cmp for non-strings should call opCmp only once per item pair

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18280

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18280] std.algorithm.comparison.cmp for non-strings should call opCmp only once per item pair

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18280

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/7f59e5ad526ee4bf856e8235e3042bb5cd442ad4
Fix Issue 18280 - std.algorithm.comparison.cmp for non-strings should call
opCmp only once per item pair

split cmp into two overloads per @andralex

https://github.com/dlang/phobos/pull/6056#pullrequestreview-90687092

Minor adjustments, again

cmp should return auto and let opCmp drive

https://github.com/dlang/phobos/pull/6056#issuecomment-359665184

Fix Issue 18285 - std.algorithm.comparison.cmp for strings with custom
predicate compares lengths wrong

Test std.algorithm.comparison.cmp when opCmp returns float

Promotions should not use cast

Optimize cmp's endgame

There are some redundant tests when the end of the ranges is reached.
Eliminated that, and improved threeWayByPred.

Fix Issue 18286 - std.algorithm.comparison.cmp for string with custom predicate
fails if distinct chars can compare equal

Fix Issue 18288 - std.algorithm.comparison.cmp for wide strings should be @safe

re-apply remove cast in promotions

https://github.com/dlang/phobos/commit/2174695151633e64c33ef8c73dcd98ae2c27606e
Merge pull request #6056 from n8sh/algorithm-cmp

Fix Issue 18280 - std.algorithm.comparison.cmp for non-strings should call
opCmp only once per item pair

--

[Issue 18292] New: Version=GC shouldn't segfault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18292

  Issue ID: 18292
   Summary: Version=GC shouldn't segfault
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

version=GC needs to be fixed first, s.t. it passes the testsuite and doesn't
segfault on the way.

Afterwards, version=GC should be run as part of the CI testsuites.
As modifying auto-tester is a PITA, probably SemaphoreCI is the best option.

--

[Issue 18252] no property 'tupleof' for type 'string[int]'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Hardware|x86 |All

--

[Issue 10128] import statement in base class members should be private by default

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10128

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--

[Issue 16057] [TDPL] synchronized (a, b) compiles and runs with wrong semantics

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16057

yebblies  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #2 from yebblies  ---
*** Issue 18277 has been marked as a duplicate of this issue. ***

--

[Issue 18277] synchronized statement with comma operator ignores first arguments

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18277

yebblies  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||yebbl...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from yebblies  ---


*** This issue has been marked as a duplicate of issue 16057 ***

--

[Issue 18252] no property 'tupleof' for type 'string[int]'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
Probably due to https://github.com/dlang/druntime/pull/1824

--

[Issue 18252] no property 'tupleof' for type 'string[int]'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Radu  changed:

   What|Removed |Added

  Component|phobos  |druntime

--

[Issue 18252] no property 'tupleof' for type 'string[int]'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

--- Comment #1 from Radu  ---
This is a regression introduced in 2.078

--

[Issue 18252] no property 'tupleof' for type 'string[int]'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18252

Radu  changed:

   What|Removed |Added

 CC||radu.raca...@gmail.com
   Severity|critical|regression

--

[Issue 18291] New: getcwd is deprecated for Windows - the ISO C++ conformant _getcwd should be used instead

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18291

  Issue ID: 18291
   Summary: getcwd is deprecated for Windows - the ISO C++
conformant _getcwd should be used instead
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Keywords: bootcamp
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

https://msdn.microsoft.com/en-us/library/ms235450.aspx
This POSIX function is deprecated. Use the ISO C++ conformant _getcwd instead.


See also:

https://github.com/dlang/dmd/pull/7757#discussion_r163367652

--

[Issue 18014] DMD test suite fails to link on Linux distros where PIC/PIE is enforced

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18014

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/252ab44d00f3427d6ed35d7823cd0844ba5f909a
Allow to run the DMD testsuite on hardened systems (#7420)

* Use a special D docker image for CircleCi

* Fix Issue 18014 - Allow to run the DMD testsuite on hardened systems

--

[Issue 14147] Compiler crash on identical functions in a single module

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14147

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/ab47b8b0cf18d14c1ffbc97df6c8fb299971170a
Issue 14147 - Compiler crash on identical functions in a single module (#7577)

* fix Issue 2789 - Functions overloads are not checked for conflicts

* Allow an overload declaration hack, which is actually used in druntime

If two extern (C) functions are just declared with different signatures,
they don't conflict.

 extern(C):
 alias sigfn_t  = void function(int);
 alias sigfn_t2 = void function(int) nothrow @nogc;
 sigfn_t  bsd_signal(int sig, sigfn_t  func);
 sigfn_t2 bsd_signal(int sig, sigfn_t2 func) nothrow @nogc;  // no error

This behavior must be reconsidered in the future.

* fix Issue 14147 - Compiler crash on identical functions in a single module

*  Allow an overload declaration hack, which is actually used in druntime

* Fix the testsuite

* PR 4396 Fixup

* Remove duplicate definition in the DMD backend

--

[Issue 18281] Compiler rejects safe code in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18281

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org
 Resolution|WONTFIX |INVALID

--- Comment #2 from Nick Treleaven  ---
anonymous4:
The following code works with -dip1000, so this is nothing to do with Turing
completeness, but this bug is still invalid:

void main() @safe
{
string foo = "foo";
string* p = 
string*[] arr = [];
}

`p` and `arr` are inferred as scope. In the original code, there are no
initializers so dmd can't infer scope.

The compiler should mention that the assignment fails because the assignee is
not scope though.

--

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16037

anonymous4  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16037

anonymous4  changed:

   What|Removed |Added

   Keywords|safe|performance
Summary|Closure allocation despite  |assigning delegate to a
   |scope variable for ternary  |scope variable shouldn't
   |operator / CondExp  |allocate closure
   Severity|major   |enhancement

--- Comment #2 from anonymous4  ---
I've run into this myself :)
Simpler example:
---
void f() //@nogc
{
int a;
void g(){ a=1; }
scope h=
h();
}
---
This shouldn't allocate closure because the delegate is assigned to a scope
variable.

--