vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vBulletin.org Site Feedback (https://vborg.vbsupport.ru/forumdisplay.php?f=7)
-   -   Sending of Hacks to the Graveyard (https://vborg.vbsupport.ru/showthread.php?t=153206)

hambil 07-25-2007 12:42 PM

Quote:

Originally Posted by GaryP (Post 1301125)
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 07-25-2007 12:51 PM

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

Princeton 07-25-2007 12:51 PM

Quote:

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=- 07-25-2007 12:54 PM

Quote:

Originally Posted by Marco van Herwaarden (Post 1301142)
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 07-25-2007 12:57 PM

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 07-25-2007 01:08 PM

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

-=Sniper=- 07-25-2007 01:08 PM

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 07-25-2007 01:14 PM

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.

nexialys 07-25-2007 01:25 PM

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 07-25-2007 01:27 PM

Quote:

Originally Posted by Princeton (Post 1301145)
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.


All times are GMT. The time now is 09:33 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01149 seconds
  • Memory Usage 1,746KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (4)pagenav_pagelink
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (10)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • pagenav_page
  • pagenav_complete
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete