- Development - lists.drupal.org

Better validation for CVS tags now deployed on cvs.drupal.org
by Derek Wright 03 Oct '08

03 Oct '08

The CVS repository used to be very forgiving in what it considered a valid release tag, especially in the 'extra' portion of the tag name. This lead to all sorts of wonky tags that creative developers came up with. My least favorite are the official release tags that end in "-dev", utterly blurring the distinction between official releases and development snapshots. Now, your official release tags must match the format documented here: http://drupal.org/node/93999 For the regexp-enabled, your tag must match this: @^DRUPAL-[567]--(\d+)-(\d+)(-(ALPHA|BETA|RC)[0-9]+)?$@ For the non-regexp-enabled, that basically means that the optional part after the drupal core branch name (e.g. "DRUPAL-6") and the required two digits for your version string (e.g. "--1-0") must be either "ALPHA", "BETA" or "RC" followed by 1 or more numbers. This will also prevent people from abusing the "extra" portion of the tag name as if it was another digit in the version string. 5.x-1.2-1 or 5.x-1.2.1 is no longer allowed. This was never supported, never intended, never documented, and update_status doesn't know what to do with it. Now, you can no longer create tags like this. The next release after 5.x-1.2 should be 5.x-1.3... For history and discussion of this change, see this issue: http://drupal.org/node/252473 Apologies I never locked down this regexp earlier. ;) Cheers, -Derek (dww) p.s. Please don't reply here. If you'd like to discuss this change, reply to issue #252473. Thanks. p.p.s. Nothing changed about the format of valid branch names. Those never had much flexibility in the first place, so there's no problem there. p.p.p.s. Before you write a nastygram about what a tyrant I am, please be aware that webchick, killes, merlinofchaos and pwolanin (among others) all support this change. ;)

4 4

project node UI changes deployed on d.o
by Derek Wright 02 Oct '08

02 Oct '08

Since I suspect there might be a backlash, and the questions [1] have already started coming in about the change, I wanted to briefly announce/summarize here. As of around 3pm PDT on 2008-10-01, all of the links to directly submit new issues are gone from project nodes on drupal.org. Duplicate issues suck a huge amount of time, and many of us maintainers spend upwards of 1/2 of our effort in our issue queues just marking things duplicate. This is a drain for maintainers, and isn't all that friendly for the end users, either. To help avoid this, we want to encourage people to view the queues and/or search for an existing issue about their topic before submitting a new one. Now, on the project nodes, you have the following issue-related choices: Support * View open issues * View all issues * View all support requests * Search issues * Report a security issue Development * View pending patches * View available tasks Note that the "View all ..." links bring you to a page that includes closed, won't fix, duplicate, etc, to improve the visibility of those issues. The "Report a security issue" link just brings you to the security team page explaining the proper procedure for reporting suspected vulnerabilities (that's been true since #218571 [2]). Every issue query result page still contains a "Create" link to submit an issue for that particular project. So, worst case, this introduces a single additional click. Furthermore, maintainers still have a "Create" link in your "My projects" [3] pages. For background on this change, check out this issue: "#310446: Remove issue creation links from project pages" [4]. Note, it's very easy to change these links (project.module provides a hook, and we're tweaking it via drupalorg.module, so my usual complaints about keeping things generic for the non-d.o use cases don't apply). So, if people have suggestions for improvements, please add them to #310446. Enjoy, -Derek (dww) p.s. I could definitely see the benefit of a "Create a new issue" link that brings you to the "view open issues" page with a drupal_set_message() about "Please look for an existing issue before you create a new one" or something. If folks are in favor of that, please reopen #310446 and let's discuss there. Thanks. [1] http://drupal.org/node/316097 [2] http://drupal.org/node/218571 [3] http://drupal.org/project/user [4] http://drupal.org/node/310446

5 5

Certify Drupal for use in Government (US) Projects
by Jon Saints 01 Oct '08

01 Oct '08

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns. Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution. The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter. I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal The standards we would need to meet with drupal are: http://csrc.nist.gov/groups/SMA/fisma/index.html My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint? If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further. Thanks Jon

23 41

Re: [development] development Digest, Vol 70, Issue 1
by Micah Tapman 01 Oct '08

01 Oct '08

I'm coming in a bit late to the U.S. government discussion but as it's an area of expertise for me I'll weigh in with some thoughts that may (or may not) be of some help. ===Warning, these are my thoughts. They are not your thoughts. They are given for free. Take them for what they are worth. Question them and do some research before taking my word for things!!!=== Software Certification Software certification in the U.S. federal government is handled under either the Common Criteria program or the Cryptographic Module Validation Program. Generally, software is (generally) certified under Common Criteria at level 2 or 4, and that software uses cryptographic modules that were/are certified under the Cryptographic Module Validation Program. For example, Drupal would qualify for a Common Criteria certification. The PHP cryptographic module used in Drupal would be certified under the Cryptographic Module Validation Program. Separating these two pieces is very important in order to assure security (the old adage about never writing "new" cryptographic functions yourself) and to make sure the government security reviewers understand what was reviewed and how it was reviewed. FISMA and NIST The Federal Information Security Management Act of 2002 consolidated most of the U.S. federal government's information security requirements and specifically tasked the U.S. National Institutes of Standards and Technology (NIST) with developing information security guidelines for all U.S. government programs. These guidelines are published in Special Publications, the most important of which is 800-53, Recommended Security Controls for Federal Information Systems. This Special Publication provides the baseline security guidance for all federal information systems, and one of those requirements is for the certification and accreditation of systems prior to deployment. Enterprise Architecture Another aspect of U.S. federal information systems is the recent (last 10 years) move to a standardized enterprise architecture. Unfortunately, the "architecture" term tends to deceive people. What enterprise architecture normally focuses on is not "architecture" as an information architect might envision it, rather it's the selection of products, software and hardware, to be used throughout an organization. For example, an agency's enterprise architecture will state which content management systems are authorized for use within the organization. This list is maintained by the agency's chief information officer and updated on a semi-regular basis. Drupal and Uncle Sam Using Drupal on a federal task requires a couple of specific steps. First, the cryptographic modules used in the system, including those used by Drupal, must be approved by the Cryptographic Module Validation Program. This is the first and most critical security hurdle, and it should be the first question the government's independent security analyst asks when they are vetting the program. Second, if Drupal is not Common Criteria certified (at least level 2), then the program needs to include security testing to ensure the product meets or exceeds the stated claims. What's this mean? It means checking to make sure Drupal performs the functions that it claims to be able to handle, such as session management or access control. Without a Common Criteria certification this testing falls on the development/program office for the new project trying to use Drupal. Third, the actual development effort must meet all of the requirements as dictated by NIST under FISMA, i.e., Special Publication 800-53. These requirements are scaled according to the security level of the system being built, from low (that means standard) to moderate (that means enhanced) to high (that means critical to the nation). All government systems must be secure, obviously, so even low (standard) security requirements are fairly onerous. High (critical) systems true enterprise class efforts with very robust security requirements. Unfortunately, the inclusion of any personally identifiable information, such as names and addresses, elevates a system to moderate (enhanced) security right off the bat. This makes development of even small systems quite complex. Fourth, the development office needs to expand on the NIST security requirements to include functional security requirements, and any other areas specific to the application being developed. Fifth, the application must be scanned and/or tested for vulnerabilities prior to deployment. Sixth, the application must be accredited (this is the second half of certification and accreditation) prior to deployment. Typically, a certification official, independent from the development office, provides an executive (the accrediting authority) with a report on the application's security posture and any deficiencies. This report is the basis for the executive's decision about whether or not to approve deployment. Deploying Drupal My recommendation for anyone trying to deploy Drupal on a federal task is to first and foremost get it on the agency's list of approved products, i.e., the enterprise architecture. This is a time consuming task but it will pay dividends. Second, standardize on a Drupal version and document exactly what cryptographic functions will be used. Cryptography is a complex and touchy subject, probably because most of us (me included) can't really understand it directly, so using an approved cryptographic module is the only way to go. If you don't, and someone asks about it, your entire project may come to a screeching halt. I'd also take the time to go through all of the requirements for the system, whether it's low, moderate, or high, in NIST Special Publication 800-53. Doing that will allow you to interact with the certification and accreditation team on their level and you'll already know all of their questions, it's also a halfway decent security requirements reference. And don't forget to also document and work to fulfill all of your application's specific security requirements! Finally, plan on doing some actual scanning testing of the application and providing this report to the accrediting authority prior to their decision about deploying the application. <self serving promotion>Penetration testing of web applications is really helpful when it comes time to answer the question, "Is this application secure enough to put out on the Internet?"</self serving promotion>. I guess that's a lot of info, to the point of being a TLDR post :-). Sorry for rambling a bit but it's a complex subject and one I've spent more time with than I care to admit. If anyone's interested in more information (you must be crazy!) feel free to drop me a line. Oh, and all this stuff only applies to normal government tasks, sensitive but unclassified stuff, not to national security efforts, those are governed under Department of Defense guidelines, not by NIST. Micah Tapman Principal Quest Consultants LLC 240-297-1014 development-request(a)drupal.org wrote: > Send development mailing list submissions to > development(a)drupal.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.drupal.org/listinfo/development > or, via email, send a message with subject or body 'help' to > development-request(a)drupal.org > > You can reach the person managing the list at > development-owner(a)drupal.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of development digest..." > > > Today's Topics: > > 1. Re: Certify Drupal for use in Government (US) Projects > (Piermaria Maraziti) > 2. Re: Certify Drupal for use in Government (US) Projects > (Bryan Ruby) > 3. Re: Certify Drupal for use in Government (US) Projects > (Jon Saints) > 4. Announcing DRUPAL-7-0-UNSTABLE-1 (Angela Byron) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 01 Oct 2008 01:02:15 +0200 > From: Piermaria Maraziti <piermaria(a)maraziti.it> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: <20080930230359.675E31440B8(a)polimnia.eridia.it> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 17.14 30/09/2008, you wrote: > > >> The "transparency" of the Drupal project was one of the government's >> big objections. >> > > Just as a quick note by a lurker: various organs of the Italian > government (Finance Ministery but not only) judged the "open" is OS > projects to be a very good element for the usual reasons addressed by > OS evangelists, also about security issues. It's a priority, to them, > also the active participation in community: giving help when they can > to receive help when they need (yep: most utilitary, not so > idealistic - but pragmatic and correct). > > Ciao! > > > --8<-----------------------------------fnord----- > Piermaria Maraziti piermaria(a)maraziti.it KALLISTI > ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA > www.gilda.it www.eridia.it www.hovistocose.it > > > > ------------------------------ > > Message: 2 > Date: Tue, 30 Sep 2008 21:47:44 -0500 > From: Bryan Ruby <bryan(a)cmsreport.com> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: <48E2E4D0.9060502(a)cmsreport.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I've read all the messages in this thread, but I want to build on what > Steven has to say here. Please allow one disclaimer so I don't get > myself in trouble. Although I work for the federal government, I do not > speak for the federal government nor from my position in the federal > government. I'm simply a Drupal fan. > > Steven is right about the number of competing standards/programs and > levels of reviews/audits/and certification that go on in the federal > government. In many of the cases with FISMA (one of the standards Joe > links to in his first message), the certification that takes place in > most agencies are for systems and not in particular a single application > such as Drupal. In many respects this is a bottom-up certification > where each person in the chain certifies to their supervisor that a > system follows agency rules, guidelines and federal laws in making sure > the system is secure, properly patched, and all risks have been > identified/minimized. It is a very difficult and laborious process in > trying to policy put into practice. > > My agency utilizes a mix of Unix, Linux, and Windows systems. On our > administrative PCs we run a mix of propriety and open source software > (we've used Thunderbird as our official email client for years). On our > operational systems all our applications and OS are open source or built > in-house applications (utilizing Java, Tcl, Python, and variations of > C). Federal agencies can and do adopt open source for their > applications. In fact, I've seen the certification process knock out > more propriety systems than open source systems especially if they're > aging systems with little in the way of user access control granted. > Every year, I have to have one necessary propriety system given an > exception since it doesn't quite meet the requirements...and this system > can't even be networked into the office LAN. > > Here is my guess as to why Drupal wasn't accepted, without getting deep > into the policy. As I said at the start, from the system owner all the > way up through the agency's management up to the CIO...EVERYONE has to > certify that the system is secure and risks have been > identified/minimized. This is especially true when it comes to > personally identifiable information (PII) and/or if the system is > outside the firewall. In order for all those people to sign on to the > certification, they each have to have an understanding of the system. > My guess is that someone was not comfortable with their own > understanding of Drupal or open source to know whether the system would > meet all the requirements (especially if they're racing to complete > budgets/certifications during the final hours of the fiscal year. The > fact is some agencies or managers in those agencies just don't have an > understanding of the open source model and are very cautious in moving > away from what they know. Eventually, we'll have to educate them. > > Joe, what strikes me as odd though is that before a project is approved > these days the security requirements are understood. It sounds to me as > if someone on the federal side didn't do their job in working with and > informing the IT Security Officer about what this project was all > about. Very interesting and I hope it never happens to me. > > BryanSD > > Steven Peck wrote: > >> Which government security review/standard? >> >> There are dozens if not hundreds of competing standards/programs and >> levels of auditing and determination depending on which department you >> are dealing with. For example just one program was formerly known as >> DITSCAP and is now DIACAP. >> >> Many of these have more to do with procedures and policies then code. >> >> Steven >> >> On Tue, Sep 30, 2008 at 8:40 AM, Jon Saints <saintsjd(a)gmail.com> wrote: >> >> >>> The names of Citizens are collected on the website along with some personal >>> contact information. We were told that our application required the Medium >>> level security certification. >>> >>> For collecting more sensitive information, certification becomes nearly >>> impossible. >>> >>> Thanks >>> Jon >>> >>> On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter >>> <gerhard(a)killesreiter.de> wrote: >>> >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Jon Saints schrieb: >>>> >>>> >>>> >>>>> On a recent project for the US government, half way through the >>>>> development process, our work was stopped by a government security >>>>> review which said that Drupal (and open source software in general) >>>>> is not suitable for use in government projects that house personal >>>>> information due to security concerns. >>>>> >>>>> >>>> Just out of interest: What kind of information are we talking about? >>>> Tax numbers, bank accounts? >>>> >>>> [...] >>>> >>>> >>>> >>>>> I notice other governments around the world are using Drupal with great >>>>> success and savings to citizens: >>>>> http://buytaert.net/new-zealand-government-using-drupal >>>>> >>>>> >>>> Seems like a showcase site only. >>>> >>>> Cheers, >>>> Gerhard >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>> >>>> iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK >>>> BX1vLaioeWG348yH/V/ufKs= >>>> =yFhK >>>> -----END PGP SIGNATURE----- >>>> >>>> >>> >>> >> >> > > > > ------------------------------ > > Message: 3 > Date: Tue, 30 Sep 2008 23:27:17 -0600 > From: "Jon Saints" <saintsjd(a)gmail.com> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: > <8e779d5d0809302227y6a2d6f41q4bf6f728a496dd9a(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for all the informative comments. The discussion has been most > helpful. > > Its does appear that our case was the result of a decision of an individual > (who maybe is not familiar with Drupal), and not a sign of general > opposition by the government to Open Source software. > > That is good to know. > > Reading through NIST's documentation it seems that certification for > software to meet the FISMA standards usually takes years. As others have > pointed out, this is just one of many different standards that the > government has for software. Its unclear to me where we could even start to > certify Drupal for government use. > > The lesson here... approval of open source tools seems to happen on a case > by case and department by department basis. Even if your project is > approved by a Department heads, ask for a review of the proposal by the > Security Officer in charge before work begins. In our case, I am not sure > why that did not happen until half way through the project. We are just > learning to work for the government. So this is a lesson we will take > carefully into all our work from here on. > > I have contacted NIST to see if I could sit down and chat with someone to > bring up some of our questions posted in this thread. If I do get a > conversation, I will be sure to post the comments back to the group here. I > have also asked them for alist of the approved content management systems so > we can get an idea of which companies/projects have achieved certification. > > Thanks > Jon > > On Tue, Sep 30, 2008 at 8:47 PM, Bryan Ruby <bryan(a)cmsreport.com> wrote: > > >> I've read all the messages in this thread, but I want to build on what >> Steven has to say here. Please allow one disclaimer so I don't get myself >> in trouble. Although I work for the federal government, I do not speak for >> the federal government nor from my position in the federal government. I'm >> simply a Drupal fan. >> >> Steven is right about the number of competing standards/programs and levels >> of reviews/audits/and certification that go on in the federal government. >> In many of the cases with FISMA (one of the standards Joe links to in his >> first message), the certification that takes place in most agencies are for >> systems and not in particular a single application such as Drupal. In many >> respects this is a bottom-up certification where each person in the chain >> certifies to their supervisor that a system follows agency rules, guidelines >> and federal laws in making sure the system is secure, properly patched, and >> all risks have been identified/minimized. It is a very difficult and >> laborious process in trying to policy put into practice. >> >> My agency utilizes a mix of Unix, Linux, and Windows systems. On our >> administrative PCs we run a mix of propriety and open source software (we've >> used Thunderbird as our official email client for years). On our >> operational systems all our applications and OS are open source or built >> in-house applications (utilizing Java, Tcl, Python, and variations of C). >> Federal agencies can and do adopt open source for their applications. In >> fact, I've seen the certification process knock out more propriety systems >> than open source systems especially if they're aging systems with little in >> the way of user access control granted. Every year, I have to have one >> necessary propriety system given an exception since it doesn't quite meet >> the requirements...and this system can't even be networked into the office >> LAN. >> >> Here is my guess as to why Drupal wasn't accepted, without getting deep >> into the policy. As I said at the start, from the system owner all the way >> up through the agency's management up to the CIO...EVERYONE has to certify >> that the system is secure and risks have been identified/minimized. This is >> especially true when it comes to personally identifiable information (PII) >> and/or if the system is outside the firewall. In order for all those people >> to sign on to the certification, they each have to have an understanding of >> the system. My guess is that someone was not comfortable with their own >> understanding of Drupal or open source to know whether the system would meet >> all the requirements (especially if they're racing to complete >> budgets/certifications during the final hours of the fiscal year. The fact >> is some agencies or managers in those agencies just don't have an >> understanding of the open source model and are very cautious in moving away >> from what they know. Eventually, we'll have to educate them. >> >> Joe, what strikes me as odd though is that before a project is approved >> these days the security requirements are understood. It sounds to me as if >> someone on the federal side didn't do their job in working with and >> informing the IT Security Officer about what this project was all about. >> Very interesting and I hope it never happens to me. >> >> BryanSD >> >> >> Steven Peck wrote: >> >> >>> Which government security review/standard? >>> >>> There are dozens if not hundreds of competing standards/programs and >>> levels of auditing and determination depending on which department you >>> are dealing with. For example just one program was formerly known as >>> DITSCAP and is now DIACAP. >>> >>> Many of these have more to do with procedures and policies then code. >>> >>> Steven >>> >>> On Tue, Sep 30, 2008 at 8:40 AM, Jon Saints <saintsjd(a)gmail.com> wrote: >>> >>> >>> >>>> The names of Citizens are collected on the website along with some >>>> personal >>>> contact information. We were told that our application required the >>>> Medium >>>> level security certification. >>>> >>>> For collecting more sensitive information, certification becomes nearly >>>> impossible. >>>> >>>> Thanks >>>> Jon >>>> >>>> On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter >>>> <gerhard(a)killesreiter.de> wrote: >>>> >>>> >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Jon Saints schrieb: >>>>> >>>>> >>>>> >>>>> >>>>>> On a recent project for the US government, half way through the >>>>>> development process, our work was stopped by a government security >>>>>> review which said that Drupal (and open source software in general) >>>>>> is not suitable for use in government projects that house personal >>>>>> information due to security concerns. >>>>>> >>>>>> >>>>>> >>>>> Just out of interest: What kind of information are we talking about? >>>>> Tax numbers, bank accounts? >>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>> >>>>>> I notice other governments around the world are using Drupal with great >>>>>> success and savings to citizens: >>>>>> http://buytaert.net/new-zealand-government-using-drupal >>>>>> >>>>>> >>>>>> >>>>> Seems like a showcase site only. >>>>> >>>>> Cheers, >>>>> Gerhard >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>>> >>>>> iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK >>>>> BX1vLaioeWG348yH/V/ufKs= >>>>> =yFhK >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >

1 0

Announcing DRUPAL-7-0-UNSTABLE-1
by Angela Byron 01 Oct '08

01 Oct '08

Please see http://drupal.org/node/311949 for back-story. Summary: "Unstable" releases are going to be periodic (probably bi-weekly-ish or as otherwise needed) "snap-shots" of what's in HEAD, intended for pre-alpha testers who want to provide very preliminary feedback, core developers rolling "epic" HEAD patches who want something that doesn't change every hour to roll against, and/or contributed module developers who want to get the jump on porting their modules against something that's not a constantly moving target. Drupal 7 is currently being developed heavily, and what is in these unstable releases bears very little resemblance to what the final release of Drupal 7 will look like; this is merely a tool for contributors to do their work more efficiently. Please note that these are called "unstable" releases for a reason. They are intended for developers only, or testers comfortable with things randomly exploding in their face. Do NOT upgrade your production sites to unstable releases. Do NOT expect APIs to remain frozen in any way between unstable releases until code freeze. I'm not going to even include instructions on how to get it, because honestly, if you can't figure it out, you really shouldn't be using it. ;) Now, that said, here's a summary of things that are included in UNSTABLE-1. For the full list, see http://cvs.drupal.org/viewvc.py/drupal/drupal/CHANGELOG.txt?revision=1.280&… which I will try to make a point of actually remembering to update next time I roll an unstable release. :P For developers: =============== - SimpleTest module, an automated code tester, is now in core, along with a bazillion tests. These (should) now all pass, so you can use this as a guideline to know whether your patches / modules have broken anything. See documentation at http://drupal.org/simpletest. http://acquia.com/files/test-results/index.html for an idea of how our overall test coverage is coming along. - A completely new database API, known as "Database: The Next Generation" (DBTNG). This involves a lot of changes, so please see the docs at http://drupal.org/node/310069. - A "code registry" which is a set of database tables holding all of the functions in all of the modules, allowing files to be lazy-loaded. This requires changes to your .info files. See http://drupal.org/node/224333#registry for more details. - WYSIWYG editors now have a hope and prayer of integrating with textareas given the new #input_format property on textareas. - Image toolkits can now be supplied by modules. This is nice, so you don't have to do awkward copying of 'image.imagemagick.inc' into the includes folder. For users: ========== - Core now offers two install profiles: a basic one that sets up stuff like an "Article" and "Page" content type, some Taxonomy vocabularies, etc. The installer requirements check also got a nice makeover and looks more like the status report page. - Removed several modules and extraneous features: Throttle module's gone, Ping module's gone, access rules are gone, that horrible wall of comment settings is gone, etc. - Added drag-and-drop to a bunch of areas (poll results, languages, etc.) that missed them in D6. - Permissions now have descriptions, and node permissions are now sorted by content type rather than by verb. Known Bugs: =========== Plenty, but the most critical one is that you can't currently upgrade 6.x => 7.x: http://drupal.org/node/303889. Actually, I suppose this could also be considered a "feature" of unstable releases, depending on your point of view. ;) Over the next couple weeks, let's continue to hammer on http://groups.drupal.org/patch-spotlight and try and have some new exciting patches in for UNSTABLE-2. :) -- Join us at Do It With Drupal! A large scale, curated education event December 10-12, New Orleans http://www.doitwithdrupal.com

1 0

Re: [development] Certify Drupal for use in Government (US) Projects
by Piermaria Maraziti 01 Oct '08

01 Oct '08

At 17.14 30/09/2008, you wrote: >The "transparency" of the Drupal project was one of the government's >big objections. Just as a quick note by a lurker: various organs of the Italian government (Finance Ministery but not only) judged the "open" is OS projects to be a very good element for the usual reasons addressed by OS evangelists, also about security issues. It's a priority, to them, also the active participation in community: giving help when they can to receive help when they need (yep: most utilitary, not so idealistic - but pragmatic and correct). Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria(a)maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it

1 0

Seeking Drupal Consultant / Individual Developer
by Davin Hutchins 29 Sep '08

29 Sep '08

Dear Drupalers, We have hired a firm with little Drupal experience to build a Drupal 5.x site for us. They have found Drupal to be challenging and need to phase out their development. We are seeking a Drupal developer local to the Washington D.C. area to consult for us in three ways: 1.) Third-party audit of the site to see what has been installed incorrectly, built incorrectly, etc. with recommendations for fixing it 2.) We have some content and theme alterations (and a mockup) to add a simple blog and other items we would like implement by Nov. 15th 3.) On going consultation (on retainer) to modify the site, install and test relevant modules, make strategic recommendations We are a well-funded non-profit staffed by video producers and journalists have worked with CNN, National Geographic, BBC, PBS. The site can be viewed at www.americannewsproject.com Please e-mail here info(a)newsproject.org with: Drupal Consultant in the subject line. NO PHONE CALLS PLEASE. -- Davin Hutchins Managing Producer American News Project (http://www.americannewsproject.com) 1050 17th Street NW, Suite 550 Washington, D.C. 20036 Video Reel: http://link.brightcove.com/services/player/bcpid1726689966 LinkedIn CV: http://www.linkedin.com/in/nomadsland

1 0

Patch Spotlight 2.0
by Angela Byron 28 Sep '08

28 Sep '08

Back during the Drupal 6.x release, a bunch of us in #drupal pioneered an idea called "Patch Spotlight" (http://drupal.org/patch/spotlight) The idea was to pick the single most critical issue in the queue, put it "bubble it up" to give it more attention, so we could hammer *all* development efforts at it until it was resolved. The page includes information for those new to patch reviewing on how to get started, as well as an overview of what the patch does to help save people from reading 100+ replies. This actually worked pretty well towards the end of 6.x release, and helped us hammer through some critical bugs pretty quickly. However, it does have some drawbacks: 1. Only one patch is featured at a time. There might be many highly critical issues at any given time, but we can only pick one. Since there are over 5,000 issues in the queue, this mechanism is unsustainable for plowing through the patch queue. 2. Said issue might be very complex (such as the current one) or only be reviewable by only a very small number of people with a particular area of expertise (such as the current one) and as such, may stagnate for months on end (such as the current one ;)). This causes the spotlight to be less effective, because people start to ignore it. 3. People have domain expertise in different areas, and it's been challenging finding enough themers, people with JS knowledge, translators, etc. to test relevant patches in the queue. Patch spotlight doesn't reach those people; only the active core developer community. So, here comes... Patch Spotlight 2.0! http://groups.drupal.org/node/5647/patch-spotlight This is a collection of wiki pages in the "Improvements to Core" group (http://groups.drupal.org/improvements-core) cross-posted to the relevant working groups, that contains a "short-list" of core issues in a variety of areas that need code written, or patches reviewed. The issues are categorized in the following way, each with its own wiki page, editable by any members of the group: * Killer feature-enablers: Issues in the critical path for enabling us to meet Dries's Drupal 7 hit list. * OMG WTF BBQ: *Seriously* critical bugs that *need* to get fixed. * DX patches: API tweaks and such that help improve the developer experience. Also, patches that affect: * Performance: Cross-posted to the High Performance group. * Usability: Cross-posted to Usability group. * Theme system: Cross-posted to the Theme Development group. * Documentation: Cross-posted to the Documentation Team group. * JavaScript: Cross-posted to the JavaScript working group. * Translations: Cross-posted to the Translations group. * Quality Assurance: Cross-posted to the Testing/QA group This list is a result of brainstorming tonight on #drupal, so might have some glaring holes. I've added a couple of starter issues to each, but feel free to take over and add additional ones to self-organize. Obviously, the fewer issues in each page, the quicker they can be moved through, so avoid using this as a personal soapbox for all your pet patches unless they really are of wider interest to folks in a particular area. So now we have: 1. A way to "spotlight" several dozen patches rather than just one. 2. A way to alert people in working groups of core issues that affect them, so that they can give input on them well before Drupal 7 is released. 3. A way for working groups to self-select important patches in their area, and prioritize and focus on them. 4. Panels! With curvy borders, even! ;) Downside is this list needs to be maintained manually, which is kind of a pain, but if enough people help out, it should go pretty slick. Looking forward to reviewing and committing your RTBC patches! :) -Angie

2 2

Threading problems?
by Dan Robinson 27 Sep '08

27 Sep '08

Hi, I'm seeing a difficult to understand error that looks like a threading issue. My application 1. Takes data from an anonymous user (node add). 2. Creates a filename based on an md5 of a secret, the endusers email, and time() 3. Saves data to the file 4. Sends an email to user with a link to the file created 5. Displays a "complete" page that has the link to the file. Operations 2 and 3 happen within a single procedure The filename is determined thusly: $filename = md5($conf['myapp_secret_salt'] + $form_state['values']['Qualifyers']['Email'] + time()); Then I prepare data and write the file, then stash the filename in $_SESSION (for use later) $_SESSION['myapp']['filename'] = $filename; $_SESSION['myapp']['UserRegFormUrl'] = $params['filenameurl']; setcookie('myapp:filename', $filename); // this is somewhat of a hack to trap errors - see below. drupal_mail('myapp', 'notify', $form_state['values']['AdditionalQs']['Email'], NULL, $params, NULL, TRUE); myapp_mail receives the filename from $params above, prepares and sends an email with a link to the file to the end-user. In step 1 above in the form I: $form['#redirect'] = 'registration/complete'; The node at registration/complete has some php in it that fetches the global variables (with the filename) and outputs a link to the file in the browser. So that is the whole process. The problem I'm having is that some users are being pointed to files that belong to other users. I believe this is happening both in the email as well as on the registration/complete form. Some people have reported receiving links to files that were for another user. Also I put some trap code in the registration/complete form. The form fetches the filename from $_SESSION and compares it to the filename in the cookie - if they don't match it errors. That code is being tripped. I looked at recent occurrence of the error and the two nodes involved (one for each of the users) had exactly the same time created timestamp. My assumptions have been: - Anonymous sessions are tied to a particular connection and data in $_SESSION is not shared. - PHP procedures are threadsafe I'm running PHP 5 on Red Hat. What am I doing wrong? Thanks, Dan

4 5

Handling optional parameters
by Nancy Wichmann 25 Sep '08

25 Sep '08

I have a module that may accept several optional parameters from the user. The "standard" way of doing this is something like "my-module/action/123/0/3/list/xyz" where everything after "123" is optional, so doesn't show up in the menu entry. I'm not crazy about this technique, although the menu system does make it easy to use. A) The user has to remember, or look up, the order of those parameters (I have to look them up because I can't remember them, and I wrote it). B) If the user is happy with an intermediate value (e.g. the "3" above), they still have to specify it in order to use "list." C) There is no flexibility. I was playing around and realized that $_GET makes getting input parameters from the query string pretty easy. It also gives me more flexibility in adding (or removing) the optional parameters, means the user doesn't have to remember the order, and means only values that are desired have to be entered. Will I be tarred and feathered for going the $_GET route? Nancy E. Wichmann, PMP No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1685 - Release Date: 9/22/2008 4:08 PM

6 6