General developer forum

function ini_get_bool2($ini_get_arg) {
    $temp = ini_get($ini_get_arg);

    if ($temp == '1' or strtolower($temp) == 'on') {
        return true;
    }
    return false;
}

function unregister_globals2() {
    $REQUEST = $_REQUEST;
    $GET = $_GET;
    $POST = $_POST;
    $COOKIE = $_COOKIE;
    if (isset ( $_SESSION )) {
        $SESSION = $_SESSION;
    }
    $FILES = $_FILES;
    $ENV = $_ENV;
    $SERVER = $_SERVER;
    foreach ($GLOBALS as $key => $value) {
        if ( $key != 'GLOBALS' && $key != 'CFG' && $key != 'nomoodlecookie' 
          && $key != 'lifetime' && $key != 'starttime') { //hacks for themes and cron
            unset ( $GLOBALS [ $key ] );
        }
    }
    $_REQUEST = $REQUEST;
    $_GET = $GET;
    $_POST = $POST;
    $_COOKIE = $COOKIE;
    if (isset ( $SESSION )) {
        $_SESSION = $SESSION;
    }
    $_FILES = $FILES;
    $_ENV = $ENV;
    $_SERVER = $SERVER;
}

if (!ini_get_bool2('magic_quotes_gpc') && ini_get_bool2('register_globals')) {
    unregister_globals2();
}

If you have a security concern, or have spotted something that looks like an exploit against Moodle, please report it via http://security.moodle.org . We usually have a fantastic turnaround time (mostly thanks to Skodak), and we'll have figured out whether it is for real, and what fixes and/or workarounds are needed, gotten back to you and made an announcement.

Posting things to security.moodle.org ensures that it gets to the eyes of the security team quickly (not everybody follows general developer forom closely). It also makes the work of the security team much easier, and prevents needless risks and panics.

Please, do this even if the vulnerability has already been posted somewhere on the internet. For real vulnerabilities, the actual risks during the exposure window depend a lot on how the information spreads. Ideally, it should spread fast among the developers who can help you, and we should not help its spread in, ahem, other communities

If you feel security.moodle.org does not address your concerns in a timely fashion, and trying to contact the core developers doesn't work (our email addresses are very public!), you can opt to discuss it in the forums. This is always risky -- if you find yourself in the unenviable position of having to discuss this in an open forum... be careful with what you post.

This approach is generally known as giving the 'vendor' (in this case the Moodle.org dev community) advance warning, and is what most people in the software and network security consider to be best practice.

For the record, the report to security.moodle.org was not made by Brian but by Miles Berry.

If anything, please read the link you yourself posted. Please read it carefully. I think you'll find, if you really reflect on the issue, that Schneier's position about full disclosure is in line with my original post that started this thread.

Hmmm. I think you are reading Schneier with some preconceptions. As I mentioned earlier, the FD debate is complex, deep and mature. As such, any interesting and well explained position will support both sides: disclosure and non-disclosure. So yes, Bruce supports Nicole, and he supports your position too. But don't feel a winner just yet. He actually ends up arguing that the only sane thing to do is "responsible disclosure" (he doesn't use that term, though).

That's why it's an interesting debate, one that you have to read with both eyes open.

If you read Bruce's discussions on the window if exposure, it depends a lot on the flow of information -- who gets it and when. That is why we definitely prefer to get the information early in the hands of the developers who you trust and can help you -- even if it's been published somewhere. And then get out of their hair while they figure out whether the thread is real and provide a fix if needed.

That's all -- plain and simple.

Everything else is noise and gets in the way.