Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Status of Recent User Information Leak

by boblawblah (Scribe)
on Aug 04, 2009 at 06:56 UTC ( #785659=note: print w/replies, xml ) Need Help??

in reply to Status of Recent User Information Leak

Shame on you. Volunteers or not - what a major betrayal of trust. Restore it.
  • Comment on Re: Status of Recent User Information Leak

Replies are listed 'Best First'.
Re^2: Status of Recent User Information Leak
by Anonymous Monk on Aug 04, 2009 at 08:14 UTC
    What were you hoping to hear, I quit?

      [From someone in the Saints list, who'd rather leave this Anonymously]

      How about some honesty? How about real honesty instead of the defensive egotistical self-centered crap that the "gods" have been posting about this?

      "We're sorry, we really screwed up."

      "We aren't competent enough to fix it quickly."

      "The PerlMonks code is so bad, even competent programmers can't fix it quickly."

      "The PerlMonks code is such crap, we can't even give it away and ask for help."

      "Many eyes will never make short work of PerlMonks bugs."

      "We laugh at places like Twitter for being insecure, but we're leaving a badly hacked, insecure system up anyway."

      "We give out lots of coding and security advice, but haven't really been listening to any."

      "We've really poorly represented the Perl community, and we're sorry."

        I only wish all of that "defensive egotistical self-centered crap", much of which I wrote, were mere excuses. Unfortunately, they are not. Should this change? Can it change? You bet. Will this change? That depends on the only people with the ability to make unfettered changes to code and site policy, the gods, of which I am not one.

        Perl Monks has a long list of pmdevs but only a very few who can make meaningful changes. The code for Perl monks is split into hundreds of micro-segments spread across a database. To fix any of the issues that you consider "crap" would require a coordinated set of change that affects multiple segments, possibly 10, 20 or more!

        Each and every change must be individually approved and tested by a god before it can be applied. There is no mechanism to submit and approve changes as a group. There is no test bed that pmdev's can use to validate their proposed changes before submitting them. There isn't even any good system documentation to show how all the code segments work together to support each custom post-Everything-I engine feature. That means that each and every significant change is a research project. For even a simple change to a system (rather than a bolt-on feature), the amount of information generated is apparently too time consuming to review. For instance, we have a pending proposed change to address the documentation situation that is still waiting for final approval (or rejection). When I last asked about its status I was told there was too much to go through at that moment - it has been over a month and it still hasn't been reviewed, approved, or rejected.

        Should there be a test bed? Yup. Why isn't there? Well, first user data, system metadata and code is all mixed together in the database. The easy part is creating a specialized query to skip over private user information and using it to generate a tarball. That has even been done already. The hard part is that security rules are all mixed up in the code rather than segregated into a separately identifiable set of code segments. There is no way to eliminate that material from the download, without extensive code review and analysis, plus changes to multiple code segments, each requiring individual approval and review. That brings us round to where we started: no testbed, too few people reviewing too many changes. It is a vicious cycle.

        Making massive changes without testing is a very stupid idea. Allowing testing and significant change would require expanding the circle of trust to include people other than the current set of gods. The current set of gods simply don't have the time to manage such a large set of changes to such an extensive codebase. This would be a lot of work for a paid team, and the gods are volunteers fitting this around their day jobs. But expanding the circle of trust also carries risks as well. At the moment the risk of change appears to the gods as greater than the risk of no change.

        So call these excuses if you may, but the management problems at Perl Monks are not technical problems that can be fixed just by "doing it". Do you have a solution to the trust dilemma? A better way to add more hands to the till?

        If so, stop spending time complaining and step to up to the plate. If you are so fussed (and you have a right to be), make yourself known, and advocate for what you think is right. Take the XP risk. And do it in a separate top-node where it will get attention. This thread is old news and the milk is already spilt. It is time to move on.

        Best, beth

        Asking for folks to be forthcoming and then posting as an anonymonk lacks .. something. That being said, I agree, but would rather we get these notification emails out.
        "We laugh at places like Twitter for being insecure, but we're leaving a badly hacked, insecure system up anyway."
        It wasn't this server that was hacked. It was an older system no longer in use but apparently still on the network. The problem now is we don't know what was done with the old server and we don't know what steps have been taken to prevent the same exploit form being used on this server. More information would seem to be in order.

        Elda Taluta; Sarks Sark; Ark Arks

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://785659]
and all is calm...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (3)
As of 2017-04-30 01:18 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (534 votes). Check out past polls.