Re: Visual D 1.0.0 released
On 4/7/20 15:00, Rainer Schuetze wrote: Hello, after having passed the 10 year anniversary of public availability recently, it is finally time to release version 1.0 of Visual D, the Visual Studio extension that adds D language support to VS 2008-2019. You can find the installer at http://rainers.github.io/visuald/visuald/StartPage.html Highlights from this release: - semantic engine based on dmd front end now enabled by default and updated to 2.092. If you are low on memory or run a 32-bit Windows, you should switch back to the legacy engine. - debugger extension mago will now evaluate struct or class properties (methods or fields) __debugOverview, __debugExpanded and __debugTextView to customize the debugger display. mago can even display forward ranges as a list, but that is currently rather slow, so it is disabled by default (see debugger options). - the bar on the top of the edit window now displays the current edit scope and allows faster navigation within a source file (needs the dmd based engine) - ever wondered how to navigate to the type of a variable declared by `auto` inference? clicking an identifier in a tool tip from intellisense will now jump to its definition (only with the dmd based engine) See https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes. Cheers, Rainer Looks great! I could only see windows installers though, and at first sight it seems to be Win only... is there any chance it would work with VSCode for linux / VSCodium (even if built manually)?
Re: A security review of the D library Crypto
On 1/7/20 9:19, Cym13 wrote: As some of you may know one of my hobbies is to review open source software for security issues. About a year ago I reviewed the RSA implementation of Crypto[1]: a native D library which, according to dub statistics, is fairly popular. Issues were found and after discussion with the author I decided to wait for them to be fixed. A year later I would like to present the results of an updated review of the library: https://breakpoint.purrfect.fr/article/review_crypto_d.html Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. “Is this really the place to have this discussion? Shouldn't this be between the author and you?“ The author was contacted a year ago and although our discussion was kind and productive I have not heard from him since. Most of the issues present today were already present in my first assessment. Some modifications were made, but most recommendations were ignored. After a year without action I feel that the users should know exactly what they are exposed to since they are the ones affected by these security issues. This follows standard vulnerability disclosure processes. For all details and analysis I direct you to the blog post. It is a rather thorough and technical read so I would recommend grabbing a cup of tea first. If you find any mistake or unclear parts I'll be glad to correct it so feel free to point it out. Furthermore if you would like someone to have a look at your project to identify issues I am always glad to help free and open source projects that can't afford security review through traditional means so feel free to reach out. [1] https://code.dlang.org/packages/crypto As somebody who also was somewhat involved in infosec and cryptography in a previous life, I found your article really interesting. So, first of all, thanks for taking the time to do the review and for publishing the results! I see that you mostly focus on the algorithms, but did you also check for side-channel attacks (for instance, timing attacks), or given the flaws already found it would make little sense to go deeper? I find that following a well-known algorithm is just the easy part when implementing crypto... the hard one is ironing out those pesky "implementation details". That's one of the reasons why I would try to use one of the "big" libraries for cryptography instead of rolling out my own, even if it meant adding an external C/C++ dependency to my project.
Re: DIP1028 - Rationale for accepting as is
On 27/5/20 11:50, Walter Bright wrote: It is a fair point. But I am looking a bit farther than that - the team that is responsible for QAing software (sometimes it is a separate team). The QA team cannot tell the difference between correctly annotated @trusted code and greenwashed code. This is a most unsubstantiated assertion. If this were the case, I would have to wonder what the QA team is there for, if they can just be replaced by an automatic lint tool. *AND* even if that were so, see below: But they can tell when code is not annotated (no, it is not harder to do, the annotations are designed to not be hidden - annotations cannot be hidden by the preprocessor nor are they propagated from imports. They have to be there, and if grep doesn't find them, they are not there. I've never had any difficulty finding the annotations belonging to a declaration). Then the coder just slaps `@safe:`, `@trusted:`, or whatever greenwashing you were trying to avoid, and we're just back to square one since, per your previous assertion, QA can't notice the difference. Heck, in such an environment I might slap `@trusted:` just in case at the beginning of each and every file and live in a land of bliss thereafter! Un-annotated C declarations should be a red flag to any competent QA team. Recognizing a false @trusted is a whole lot harder. Exactly, which is why they should be disallowed by the compiler. Considering them `@system` by default is a way to do it. Another (perhaps even better) already proposed one would be to actually consider them `@safe`, but disallow `@safe` declarations where the code can't be analyzed by the compiler (it would be debatable if the mangling should be enough or not). BTW, one good thing that has come out of this issue is people are strongly in favor of what @safe does. That bodes well for DIP1000 and the @live code, for a long time I seemed to be the only one who cared about it. Being in favour of what @safe purports to do and in favour of what it actually does are two very different things. The whole selling point of @safe used to be "you're only responsible for `@trusted` code, now that's no longer true (or at least even less, if we account for the already existing holes). The direction of travel is opposite to the announced destination. I also have no problem if the D style checker checked for un-annotated C declarations. That's the kind of thing it's for. So, if you leave them for the style checker that means that you envision cases where this could be the desired behaviour, otherwise you should just let the compiler error. What would these cases look like? Because I can't imagine any.
Re: DIP1028 - Rationale for accepting as is
On 24/5/20 5:28, Walter Bright wrote:
I'd like to emphasize:
1. It is not possible for the compiler to check any declarations where
the implementation is not available. Not in D, not in any language.
Declaring a declaration safe does not make it safe.
Here, I agree with Timon: only @system and @trusted should be possible,
and in my personal view it should be mandatory to annotate external
declarations. If not, at least default to `@system`.
2. If un-annotated declarations cause a compile time error, it is highly
likely the programmer will resort to "greenwashing" - just slapping
@safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've
all done it. Sometimes even for good reasons.
So the compiler helpfully does the "greenwashing" for us. How is that an
improvement in any way?
3. Un-annotated declarations are easily detectable in a code review.
No, they are not. If somebody slaps `@trusted:` at the beginning of a
file, that's a conscious decision, there will be a commit for that.
Fingers can be pointed and questions asked.
If the compiler silently does it's highly likely that many people won't
notice, and at the very least there will be plausible deniability
("sure, boss, I didn't know you had to slap `@system` to our C
declarations, also, I was using @safe and the compiler didn't complain").
4. Greenwashing is not easily detectable in a code review.
I would say that greping for `@trusted:` is no that hard. I'm pretty
sure tools like d-scanner are more than able to catch the more advanced
cases.
5. Greenwashing doesn't fix anything. The code is not safer. It's an
illusion, not a guarantee.
Yet the compiler will just do it, breaking all the promises for `@safe`
code in the process. Now the whole `@safe` concept becomes the same
"illusion".
6. If someone cares to annotate declarations, it means he has at least
thought about it, because he doesn't need to. Hence it's more likely to
be correct than when greenwashed.
Q.E.D.
How come this doesn't apply to the compiler?
7. D should *not* make it worthwhile for people to greenwash code.
Then just disallow blanket greenwashing at all. You're just making the
case for forbidding `@trusted:`, and that's something I'd totally support.
Or make it so that function declarations need
It is, in a not-at-all obvious way, safer for C declarations to default
to being safe.
It's definitely one of most not-obvious things I've ever seen here.
Re: DIP1028 - Rationale for accepting as is
On 24/5/20 0:38, ag0aep6g wrote:
On 24.05.20 00:17, Arafel wrote:
On 24/5/20 0:02, ag0aep6g wrote:
... and @system static constructors and `--boundscheck=off` and
initializers of globals
Other than `--boundscheck=off`, that is presumably actively chosen by
the user (as is @trust), would the others be allowed without
`@trusted` in otherwise 100% @safe code?
Yup. Today they can be unmarked, defaulting to @system. With DIP 1028,
they can be explicitly marked @system. Either way, they don't show up
when you only look for "@trusted".
I would find concerning that any @system code is allowed, but I guess
initializers of globals should be ok as long as they are @safe
themselves?
As long as they're @safe, sure. But they can also be @system.
An example:
const int x = 42;
const int y = 43;
void main() @safe
{
import std.stdio;
writeln(x, " ", y); /* Prints "42 43" as expected. */
auto px =
auto py =
writeln(*px, " ", *py); /* Prints "13 14". Wat? */
}
int* p = cast(int*)
static this() @system { *p = 13; *++p = 14; }
I find this... disturbing... what is worse, it also happens with
`immutable`.
Then there should most definitely be a list of features to look (in
addition to `@trusted`) if you want to make sure your `@safe` code is
actually safe.
Re: DIP1028 - Rationale for accepting as is
On 24/5/20 0:02, ag0aep6g wrote: ... and @system static constructors and `--boundscheck=off` and initializers of globals Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe code? I would find concerning that any @system code is allowed, but I guess initializers of globals should be ok as long as they are @safe themselves?
Re: DIP1028 - Rationale for accepting as is
On 23/5/20 20:40, Johannes T wrote: On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote: I have made these points before, but I'll summarize them here for convenient referral. [..] Thank you for the detailed and insightful explanation. Would it be feasible to have a follow-up DIP that enables implicit @system extern as an opt-in (e.g. -nosafeextern). The frustration most people seem to have with @safe extern is that it lessens the promise of @safe without a recourse. Also there will need to be an answer to this probably inthe future not unusual question: My code is 100% @safe, there's no @trusted block anywhere, why am I getting memory corruption? To me the expectation / promise was that @safe code was safe from memory corruption modulo bugs in the implementation. The only source for issues would be then @trusted code that could be audited as needed. You could say "well, you always had to check for those", but the difference is that until now the compiler would shout at me if I didn't, so I wouldn't forget about them. Now it has to be clearly explained that you should check for @trusted code AND unmarked external C functions.
Re: Encouraging preliminary results implementing memcpy in D
Well, e-mail was never meant to be reliable or secure... BTW, there are already solutions to prevent impersonation: sign the messages with either PGP or S/MIME... the former is more decentralised, and the later usually comes together with stronger verifications, like personal identification of the sender (I mean, whoever issues the certificate for S/MIME should ideally check your name, etc.) :-) Although admittedly that'd work only for the NNTP / mailing list, I don't know how that could be adapted to the web "forum" interface... On 06/14/2018 05:59 AM, Cym13 wrote: Hopefully once that particular user gets discouraged or we find a way to actually avoid user impersonification, then things will be able to come back to normal.
Re: DIP1004: Inherited Constructors
On Monday, 28 November 2016 at 02:38:00 UTC, Dicebot wrote:
DIP 1004 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/42
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
If you want the change to be approved and have ideas how to
improve it to better match on
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
existing published reviews - please submit new PR with
editorial and ping original author.
I think I might be a bit late to the party, and I'm still quite
new in D... but wouldn't a variadic template constructor work?
The usual rules of templates would still let you override a
constructor if needed.
---
class A {
this() { }
this(int a) { }
}
class B : A {
// Here we inherit all of A's constructors.
this(Args...)(Args args) {
super(args);
}
this(string s) { }
}
void main() {
B b1 = new B(42);
B b2 = new B("foo");
}
---
I've been playing with it, and the only problems I can see are
with specialization and casting (i.e. B defines this(float), but
you want to call A's this(int), the int will be promoted to float
and B's version will be used). A way of disabling them would be
needed, though... perhaps assert(0)?
