This is why I don't use D.

Everlast Everlast at For.Ever
Sat Sep 8 01:32:19 UTC 2018


On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh 
wrote:
> On Saturday, 8 September 2018 at 00:04:08 UTC, Everlast wrote:
>> Seems there are a few good suggestions.
>>
>> Here is another:
>>
>> Have dub have the ability to submit patches when a previously 
>> broken package compiles.
>
> So I identify a package that doesn't compile anymore and submit 
> a patch that adds a bitcoin miner and sets fire to your cat?

There are ways around this:

1. If the code is just a few lines and does not escape then it is 
marked safe and is safe.

This probably gets at least 50% of all patches because it is from 
a bug that is a few lines of code.

2. Require users to log in to be able to submit changes. Users 
must wait a week after registering to sub changes and can only 
submit so many changes per day.
They can submit more but they are flagged.

3. Commits to the end user side can be reviewed.

4. A forum thread is generated for each project with sub threads 
for each commit. These can be "rated" for how well they fix the 
problem by others and people can discuss them, sort of like 
bugzilla but better(more forum like).


5. large changes are automatically committed but are not 
automatically used. They must be marked as valid by the 
maintainer of the project or the community.


Basically your argument is that we should throw the baby out with 
the bath water because MAYBE the baby will grow up to be Hitler. 
Your logic is the same as cops who say "I should kill this guy 
now because MAYBE he has a gun" or any other insane thing that is 
a "MAYBE" but actually very unlikely.


Instead of assuming the most unlikely case, which is insane, it 
is better to assume the most likely case and then add in the 
necessary checks to deal with the unlikely cases.


Because, you know, I could download a dub package right now that 
does exactly what you just said, so it is really irrelevant. The 
only thing having dub automatically handle it all for you would 
do is give someone a little more incentive to try and make it 
happen that way. But seriously, do you think this would be a 
common attack vector for psychopaths?

When you make it 99.9999% likely they will be ineffective then 
who cares what they do. If it does happen, the chances are it 
will fail for various reasons. It it is probably 1 in a billion 
shot that they will create a patch that will be effective for 
what they want(to get your bank account, or whatever).

It's much more likely that other routes would be more effective 
and since psychopaths are only worried about being successful 
they are not going to waste their time with an attack vector that 
is almost surely not going to succeed.

Basically those that are in such a secure environment are also 
not going to make it easy(e.g., they will use a VM alternate OS, 
sandbox, etc).

Those that don't really care don't have much to lose so it 
wouldn't matter if the attacker was successful.

6. Users can define levels for automatically including code - 0 
for automatic, all cases
1 - When patches do not escape
2 - When patches do not escape and are less than x KB or y lines.
3 - When forum rating > 10 people and 90%
...
X - Review all changes
Y - Ignore all
etc...

This way paranoid users can opt out. If, say, psychopaths do 
start using D to spread their insanity, then people can just 
switch to a more secure level and it will squash the problem 
quickly making it less an incentive for the attackers.


So, you see, there are plenty of solutions that can solve your 
hypothetical reason for squashing something that would be very 
practical.

There is absolutely no reason to throw the baby out... none! 
Don't allow it to turn in to a Hitler, it's not the babies fault, 
it's yours for what you teach it.

Meaning, there is no reason to not have dub automate everything 
as much as possible for hypothetical security concerns... Teach 
dub how to deal with them to a high enough degree that anyone 
attempting such things will be shut down quickly. It's not 100% 
but nothing is. After all, we are not even talking about 
something that hackers have ever used as an attack vector 
before... it's not even in the realm of what they are after(it's 
not just system control because most systems are useless).


> If dub packages were scoped to a user, then you could fork a 
> dub package more easily. Then the dub registry page for that 
> package could contain both the information "this package 
> doesn't compile with DMD > 2.65.0" and "this package has a more 
> up-to-date fork that compiles with DMD > 2.068.0".
>
> That means I can't hijack your project, which is good, but 
> updating broken dependencies takes manual intervention, which 
> is bad.

Yes, but if one just makes it a bit more intelligent one can 
solve the problem PROPERLY!

I'm not saying my solutions are what should be done because I'm 
just throwing out rough ideas. What I'm saying is that THERE IS A 
PROPER SOLUTION!

It would take people communicating in an organized and structured 
way to come up with that proper solution.

This means a group of people deciding that it should be done and 
that they will work together to solve the problem by coming up 
with the correct solution then coding that solution. It would 
take months, not days and it would involve a lot of people 
working together which requires organization to be effective. It 
can't be done on a forum like this.





More information about the Digitalmars-d mailing list