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.
