Well, thats a fairly common argument and point of view that is far to simplistic to be realistic. Theres a whole host of people in pmdev, many of them quality programmers, in addition joining pmdev is mostly a matter of being of sufficient level on the site (to show that you are "responsible" in some way) and that a god has approved your membership. And thats about it. So the bar we set for who can see the code is fairly low. Having said that the way the code is structured its difficult and time consuming to do a proper security analysis so preventing random script kiddies with too much time on their hands the opportunity to find issues is merely prudent.

Ultimately the truth is that secrecy and information control are effective parts of any overall security picture. Relying on any one aspect of the security portfolio to secure your site is unwise, using them all together is not.

Ask yourself, if you were in charge of a military base would you publish the blueprints and engineers diagrams and specs on the bulletin-board outside? Of course you wouldn't.

Anyway, if it were possible to conduct a propper security review of the current code base to satisfy the gods paranoia then I suspect there would be no argument about opening things up. Until then however its gunna stay more or less "need-to-know". This isnt the codebase to a kernal being distributed widely and tested severly before it gets installed for production use, its a production web site with a reasonable load on donated equipement of interest only to a few interested perlmonks and possibly some crackers so IMO the benefits of an open code base would come at a cost we cannot afford.

Ask yourself, if you were in charge of a military base would you publish the blueprints and engineers diagrams and specs on the bulletin-board outside? Of course you wouldn't.

I know secrecy may be good, or necessary. But we're not talking about the super-duper secret bomber plane here, merely a web-based bulletin-board :) Security IS important, sure. But it's only a website, it doesn't even runs a business after all (nobody will lose his job if PM is defaced, isn't it?)
Actually I don't really mind seeing the PM code or not. I just wanted to throw some fuel into the usual flamewar know :)

But it's only a website, it doesn't even runs a business after all (nobody will lose his job if PM is defaced, isn't it?)

If the system were properly compromised they could use it as a stepping stone to other sites managed by our noble hosts which would almost certainly result in them terminating their fine support of our organization. And then where would we be? No, while we are all volunteers I think most of us active participants take our roles pretty seriously and we will never knowingly do anything to allow such a thing to occur.

---
$world=~s/war/peace/g

How ironic. The "security through obscurity" criticism is a pure "cargo cult" phrase. It appears that many remember the phrase but few remember the context in which it actually makes sense. Obscurity is almost always a part of a security system. If not, then why don't you post your PerlMonks password in your signature? Why do you feel you must obscure it? Why do you obscure your private key? Duh.

The phrase was coined because people were making up encryption algorithms for wide-spread use with no apparent regard to any research in the field of encryption. They kept the algorithm secret in hopes of improving the security of the resulting system. So they prevented any review of their design, which is a good way to prevent the design from being improved.

Certainly, the obscurity made the already-written algorithm a bit more secure. Unfortunately, it prevented improvements that would increase the security by modifying the algorithm from being identified. So the system was made more secure in the short term but was made less secure in the long term by closing down the potential for suggestions of better algorithms.

Let me quote myself:

Also,

security by obscurity is no security at all.

I understand the point of that old saw, but it isn't actually true. A great deal of security is obscurity. If I were designing a new system, then I'd certainly open the design to public review rather than keep the design secret. That is quite a bit different than having a live system that has had several security problems found (and fixed) in the last few months.

Opening up free access to the source could certainly increase the rate at which any remaining security problems are found. However, there wouldn't be a team looking specifically for security problems so the ones found would most likely be by people doing the looking for "bad" reasons and so we might not even get the security problems fixed if they are exploited subtley enough.

[Someone] couldn't have guessed how to munge things without access to the source. I'll take a layer of obscurity until such time as a good security review of the site has been completed.

The other problem is wasted time. If we start getting patches from random people who think they are helping but don't have a solid clue, then we just make the resource problem worse. I've personally lobbied and gotten gods added specifically to help get the good patches that you guys have already provided but us deadbeats haven't applied.

So I think the best plan for "getting help" is to continue to add people who meet the requirements of 1) trust and 2) competence to pmdev if they show an interest in contributing.

So, as new code is written for PerlMonks, it is reviewed. I often post such code in public on the site.

If the PerlMonks code was being pushed out to be used on other web sites, then I'd also be much more interested in opening up the source code for review. But even then, the source code would likely be the latest release and proposed changes to releases. It would not be the live code.

All members of pmdev can see the live code. This fact has already been used by a (former) pmdev member to "hack" the site. Luckily, the results of the hack were fairly minor.

I'm getting more and more of the code reviewed such that I'm not worried about security issues with more parts of it. But I don't think it will ever be a good idea to have public access to the live code.

Most of the code at PerlMonks has already been made public either as part of an Everything release or as part of reviewing proposed changes. The rest of it has been open to review by a large group of volunteers.

You see, tye, I'm pretty happy with my silly joke after all, because it led you to write a more interesting post (than mine).