Sending of Hacks to the Graveyard

[hambil]

Originally Posted by GaryP

Imagine for a minute that you buy a tin of beans from a shop. Now the next day the manufactorer finds that a bit has broke off the machine.

Really it's like everything - if you know something is dangerous would you still do it? If going down a mountain do you take the path, the cable car or jump from the top? If you opt for the cablecar then find out that the cable is frayed, would you still use it while waiting for it to be fixed?

But those examples aren't like 'everything'. They are life and death. Anytime something is a matter of life and death companies always immediately inform everyone (let's not get into automobile recalls that are not done or delayed - yes companies make evil decision, too but as a rule in life and death people are immediately informed).

Nothing on this site will kill you.

[Marco van Herwaarden]

But it might kill the data that took you years to get on your site.....

[Princeton]

Nothing on this site will kill you.

but it will cause hardship .. many members devote hours to their sites - in some cases this is their livelihood that we our dealing with.

Our priority is to protect our members.

Can we find a balance between protecting members and making our coders happy?
We are discussing the matter.

I would like to hear more SOLUTIONS - instead of what's better and for whom it should favor. Who knows .. it may be something we haven't thought about.

[-=Sniper=-]

Originally Posted by Marco van Herwaarden

But it might kill the data that took you years to get on your site.....

well have you considered the FACT instructing users to uninstall a mod would do the same thing, not everyone backups their data or knows that on on uninstalling the mod it would remove the related database tables. Now the mod could be a gallery or a article system etc

[Marco van Herwaarden]

One of the improvements we are currently discussing (and i think this has already been mentioned in this thread) is if we can give a more tailored advice based on the type of vulnerability and the modification in question to the users. This might however not be possible as we can not be aware of all the ins and outs of a modification and how to block only access to vulnerable locations in the modification.

[deezelpope]

<i>This is just my opinion, but I think the current solution is acceptable.</i>

[-=Sniper=-]

asking users to disable is fair enough but no doubt the same doesn't apply to hacks which require file uploads as mentioned before.

I would rather, considering the mods are are aware of the issue, when sending out the email suggest a temp fix.

e.g. The vulnerability has been discovered for hack xx, in order to fix the the vulnerability please follow these steps (write steps) or disable the product and wait for the author to upload the fixed version.

I can understand it would not be possible if there are many locations within the code but if its only two or three, it isnt much work.

[Andreas]

Suggestion:

1. If it's a plugin only modification and the vulnerbilitie lies in the code or added templates, advise users to disable it
2. If it's a vulnerbilitie in a template modification that would still exist if all plugins are disable, advise users to revert the template(s)
3. If the vulnerbilitie lies in added files, advise users to disable the modification and delete all files added by the modification
4. If the vulnerbilitie lies in code added/modified in vBulletin files, advise users to overwrite files with the original ones

This way, it should be possible to protect users whil keeping them from loosing data.
Though, this provides more information about the type of vulnerbilitie - information that could be abused for searching the vulnerbilitie and exploiting it.

MY SOLUTION: a PR technician...

one of the guys upthere is reserved for community/coders contacts... that person is the one to contact coders when something goes wrong with any code, that person also is the one moderating these releases when things go wrong...

if the author can't be reached, the hack is stored and members alerted.

if the author is reached, the PR guy is the one to contact the coder, in the minute a exploit/problem is found, and if a solution come, they all update the release... i would suggest 24 hours, but as said earlier, usually when an exploit is found the solution came with it... we all know how to code here!...

there is 2 switches actually:

1- problem fixed: we alert everybody who have downloaded the hack to update
2- problem not fixed / author unreached: we alert everybody who download to disable the tool

it's just a question of what to say to everybody... not only the ones who clicked the INSTALL button... i never click these, and i downloaded most of the hacks released here... maybe i would miss the alert.

when Ford have to recall the entire line of a car, they do not contact only the persons who signed a newsletter, they contact all the buyers, and even make an announcement in the News...

[MaryTheG(r)eek]

Originally Posted by Princeton

Can we find a balance between protecting members and making our coders happy?

A first step is to inform members to Disable a product and not to uninstall it. Most members don't know that by uninstalling it they're loosing their data. I realized it from a huge amount of emails that I got from members asking me (but after uninstallation) if they lost their data.