Slashdot Mirror

any CGI program + any non-Debian Linux => vulnerable

No, only CGI programs that use system/popen/etc to call out to things that may be bash.

Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.

For instance, care to guess whether this one is safe?

For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.

I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.

For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

Even if you don't call out to the shell yourself, the standard library might.

Pop quiz 1: How is the PHP mail function implemented?

Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?

I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.

It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.

Answers to pop quiz:

1. popen to execute sendmail program.

2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).

These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...

http://linux.slashdot.org/comments.pl?sid=2604450&cid=38607200

Question: How's "bugzilla" doing?

Answer: It's DOWN FOR THE COUNT (on Linux)

Nope. For one https://bugzilla.kernel.org is up and running. For two, the bugzilla PROJECT is hosted at http://www.bugzilla.org and is totally independent of kernel.org (kernel.org uses it, just like you use Windows, that doesn't make Windows a stupid troll like you). So your posts are pointless and obviously trollish. That or you're too dense to understand it.

  APK EPIC FAIL... period!

Basically, bugs have a lifecycle - they may start out UNCOnfirmed, move to confirmed, then in progress, then resolved and finally rest in verified.

I used to do volunteer triage for Mozilla back in 2000 (folks like Gerv, Timeless and Asa probably don't remember me though ;). I even have an old out of date page called kill-unco.

However the reality is that there a lot of people filing bugs at a rate that is very high. Generally speaking there are not enough people to look at bugs at the best of times and this leads to a never ending amount of work. Bugs that poorly written, bugs that need to be followed up, bugs that are feature requests, bugs that are old and really difficult to fix and so on all take up vast amounts of time.

To handle this, people looking at bugs need to spend less time (or magically grow in number) in order to handle the ever increasing load. However being terse can lead to its own problems and the inevitable fall out occurs. The person in this blog post seems to be saying "Triagers are people too! We need more people doing triage full time" but the reality is this situation has existed since the beginning. Triage is a thankless, unfashionable task and the better you do it the more work you attract. It does teach how to write a really good bug report though :)

Bugzilla can run over http://www.bugzilla.org/docs/3.0/html/installation.html>mod_perl. Without it (in pure CGI use) it's a nightmare to use. With it, it can be tolerable. I'd guess (I'd hope) bugzilla.mozilla.org runs mod_perl.

Enterprise Architect is very nice, since you can do forward and reverse software engineering with it.

However, if you do not have the budget allocated for it, a good compromise is StarUML,
which became very nice and usable lately and has the same "feeling" and menu-driven approach
like the old Rational Rose and Enterprise Architect:

http://staruml.sourceforge.net/

http://sourceforge.net/projects/staruml/files/staruml/5.0/staruml-5.0-with-cm.exe/download

As for Rational Rose, the first original version was very good with some known quirks until it
became IBM Rational Rose and was converted into a "super Eclipse" plug-in.

So, if you enjoyed drawing UML diagrams in the old Rational Rose,
then Enterprise Architect and StarUML are the tools that you are looking for.

And if you do not like to draw with a mouse then Graphviz Dot and a good text editor is for you:
http://www.graphviz.org/Download.php

For tracking issues / documents and schedule,
I can recommend either BugZilla, Mantis or BaseCamp:

http://www.bugzilla.org/download/

http://www.mantisbt.org/

http://basecamphq.com/

As for the actual writing part, your company should already have a good set of Word Templates,
to document the actual Sofware Requirement and Specification (SRS), Sofware Design Document (SDD),
Change Request Document (CRD).

Once, you got those set up, then we mostly use MantisBT or BaseCamp to share, comment and track them.

As for producing code documentation, the choice are: Doxygen, JavaDoc, NDoc, JsDoc:

http://www.doxygen.org/

http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html

http://ndoc.sourceforge.net/

1. What revision control software are you using?
2. What system do you use for tracking bugs?
3. Are you familiar with Capability Maturity Model Integration (CMMI)? If so, what level certification have you achieved?

If they respond to #1 with a blank stare or "huh?" I'd advise running for the door. If they are not using any kind of revision control software, and don't know what it is, the place is very poorly managed and will cause you some serious nightmares. All of the places where I've worked, which didn't use revision control, went out of business within a couple years.

Personally, I prefer Subversion, and I converted my prior employer to using it. They didn't understand why I wanted to use it, but they weren't averse to trying something new. After it saved our butts a couple times, they understood perfectly well why I wanted to use it and continue to use it after I left.

The job before that, I used StarTeam. Borland bought StarBase (the maker of StarTeam) while I was with that employer.

My current employer uses CVS. It has its warts, but it works.

For question #2, my current employer uses Bugzilla. It works reasonably well. My prior employer didn't have a bug-tracking system. The second or third web app they had me write was a bug-tracking system, not oriented toward software development but toward the larger company (hospitality). We ended up using a wiki for bug-tracking. StarTeam had a "Change Control" system built into it, so that employer had excellent bug-tracking software.

I've had only one employer who knew what CMMI was (question #3). They could've passed a level 3 certification if necessary. If you're going to develop for the DoD, you used to need a level 4 cert; not sure if that's the case any more.

For those who don't know, CMMI is merely a methodology for ensuring that:

• coding standards are in place
• development documentation is in place
• the project is well-managed on, time, responsibilities and risks
• there is a reasonable probability of delivering on-time

It can be tedious, consistent, or both. The better places are the latter, not so much the former.

In short, they should have good, solid answers for #1 and #2, while #3 is a nice-to-have.

Bugzilla's demo site is http://landfill.bugzilla.org/ - go ahead and file junk bugs there, nobody would care.

People talk a lot of smack about office Wikis. It is true that most people aren't going to edit them or keep their "assigned" parts up to date, I've realized that now. However, that doesn't mean that it isn't an invaluable tool for YOU personally. It gives managers the ability to see details what you're doing, and its a wonderful training tool.

When I came to my current job, there was no process. No specifications, no standards; 600,000 lines of spaghetti pascal code and probably 100-or-so installations with no version information or bug tracking. The code wasn't even under RCS. I can't say that I've solved all these problems 100%, but I'm well on my way. Using my experience as a guide, here's the steps from no standards to some standards:

1. Get all moving targets under revision control, and write up a simple method of version tagging. This includes software, user documentation, database scripts, etc.

2. Start a Wiki and make a short page for each project. Make rough pages outlining things like the release process and version tagging (as mentioned in #1). Include any developer instructions such as build instructions and dependency lists.

3. Use a ticket tracking system for problem resolution, both internally and externanly. I use OTRS, and that is pretty functional (and F/OSS). Bugzilla is good too but is a little more quick-and-dirty.

Get that done, and you're well on your way. About 20 years later, and you'll get ISO!

-dave

http://weblog.timaltman.com/node/834

Like the blogger says, there's basically no way to file a bug report with Microsoft short of using snail mail or paying for support. I've never been anything but impressed with the people I've met at Microsoft, but their customer service and QA staff must be completely out of their little minds. I went through the same hoops described in the blog post above when pointing out that Always On Top windows behaved in a glitchy manner when running a full-screen RDP session on multiple monitors - Got my bug report bounced back to me no less than 5 times through 5 different forms before I gave up and started using radmin.

Lord forbid they, like every sane and reasonable company out there, set up a real bug reporting page.

Specifically in this case it seems that of the 17 available localizations only Japanese in an initial release form is currently available for the 3.0 version. The most recent available Polish versions are for 2.20 and 2.18 which is as fresh as any other localized package apart from Japanese. This is another example of localization trailing development instead of being integrated with it. (Reference: bugzilla download localizations)

bugzilla is actually written in perl.

My team just finished evaluating issue trackers, and the final three that we came up with were Bugzilla, Trac and Mantis for both technical and political reasons (Mantis is used elsewhere in the company but that's not saying much since we're so big).

We ended up deciding on Trac because of its wonderful integration with SVN, we are using a lot of python in other areas of our team and it is pretty well documented, there is a great wealth of easy to install (but not always well written) plugins and other than some quirks with the ClearSiler package it is no harder to install than any of the other packages we evaluated. If you use the subversion repository (which can be used for more than code), it is really easy to make links to other tickets, specific documents inside the repository and specific revisions.

However, Trac requires Python (you'll probably want 2.5 as the next release will require it) and either mod_python or fastCGI with a compatible webserver in addition to a subversion repository. Depending on what database you choose (SQLite3 is the default but you can also use Postgre and MySQL but the MySQL support isn't perfect yet) you will have to install the appropriate Python bindings for it and if you install the current stable release you will also need ClearSilver (but make sure you check the Trac Wiki before you install as people seem to have trouble unless they use specific versions of ClearSilver).

http://www.bugzilla.org/

I tend to do basically what MPlayer does nowadays, and that includes using Subversion for SCM, Bugzilla for bugs, Mailman for mailing lists, and Apache HTTPD for serving it all. I like to maintain a Debian Sid package (you can't directly upload to stable or testing anyhow, so the Debian maintainers will take care of adapting the package for those distros), and if someone else on the team knows anything about RPM, we also maintain the .spec file as well. I also like to keep an emerge script in there as well, but even if I didn't, someone would write one faster than you can bootstrap a Gentoo Mac Pro, so there's nothing to worry about there.

Microsoft's Linux-pro, Bill Hilf pulled out of the Linux World conference in Australia, but speaks with Computerworld anyway about what exactly his team gets up to.

There has been plenty of speculation as to why you have pulled out of the conference - but what is the real reason?

I had a scheduling conflict for an internal meeting that could not be moved. Believe me, I would much rather be at LinuxWorld in Sydney.

He talks about how Microsoft plans to make money from Linux...

How does Microsoft plan to make money from open source and Linux?

Microsoft recognizes the benefits as well as the drawbacks of the OSS development model. We are incorporating its most positive elements into our development practices. Our top priority is to produce great software that meets the needs of our customers, partners, and other constituent communities. We recently embarked on interoperability projects with SugarCRM and Jboss, open source vendors you normally wouldn't associate with Microsoft. The reason we pursued these relationships is because in both cases nearly half of their customer base is running Windows Server. By working with these companies, we can help our joint customers ease interoperability issues. The deals are also a prime example of the success partners are finding on the Windows platform regardless of the development model they employ.

1) E-mail is not a file transfer protocol.
2) Public folders (in the Microsoft Exchange sense) are not meant for use as a file server

Next you have to get management to purchase a couple things:

1) An on-demand e-mail archival solution. This product should integrate with your MUA (probably Outlook). The users should be able to locate and extract an archived email from the archival solution quickly and with minimal effort; otherwise the solution will not be utilized.
2) A better spam filter. I'd be willing to bet that a large part of your mail store is spam. There is no auditing requirement to archive non-business-related e-mail. Can the spam.
3) A web-based file-transfer/file-sharing solution. Since you're going to stop people from receiving large attachments via email (you are, aren't you?) you need to provide a method of transfer. One method is to use any of a hundred free or commercial trouble ticketing products like Request Tracker or even Bugzilla to create a secure way to transfer files between an external source and an internal employee by attaching files to an open and assigned ticket. There are numerous products out there that can satisfy this requirement, especially in these post-Sarbanes-Oxley/HIPAA/GLBA/etc times.

Next up is to clean up the PST nigthmare. I was recently involved as a consultant in the IT department of a company about your size. Dozens of their users had reached the 2GB PST limit numerous times. Their PSTs were rotated out and they simply started a new PST. The old PSTs were of course opened automatically within Outlook. These PSTs were stored on the company's main file server in the users' home directories. At some point we eventually realized that all incoming mail was delivered straight to PST instead of the users' mail spools in the information store. The day after this one of our Windows admins happened to notice that the text of the users' home directories were blue. That's right; they were compressed. Whoops! As a temporary solution for a failing mail server the previous admin staff decided to deliver mail straight to PSTs. This of course became the long-term practice. Soon they ran low on disk space. To solve this the temporarily enabled compression on the single large volume that this Windows server served to the LAN. This too became the long-term solution. Uncompressed I want to say that the data was around 800GB. Compressed it was 450GB or so. The admin staff didn't tell management what was going on and to the best of my knowledge management didn't ask or simply thought all was well. Our Windows admins are still trying to clean up this mess and these are the best Windows guys I've ever met.

Instigate policies that limit the amount of time received mail, sent items, deleted mail, drafts, etc are kept in the main inbox. A good archival solution should be able to mimick your policy in its config. Delete the deleted items daily. Dump the drafts every 2 weeks. Archive the sent items once a month. Archive the inbox every 3 months (quarterly, twice a year, whatever fits your needs).

Above all you have to get management's support and backing. Without that your pissing in the wind. Some squeaky-wheel middle management person with a Napolean-complex will put the brakes on the whole thing if you don't have upper-management's support. To get this support show them in dollars how much it would cost to restore the entire PST collection if you had a SAN failure (you do have a SAN, don't you?). Show them how much time you spend each week restoring mailboxes of enourmous size. Show management auditing requirements and how you don't meet them with your current setup. There's a lot you can do. Best of luck.

It looks like you have two options, get a dedicated server from someone like EV1 Servers for $99/month or setup your own box on your broadband connection (assuming you have broadband). I use EV1 and I would recommend them if you want a dedicated server and are willing to do your own system administration.

As far as software I'd recommend Subversion for source countrol, Bugzilla for bug tracking, and MediaWiki for general documentation. I'm in the process of setting this up for my own projects right now.

my superiors wouldn't allow any sort of bugtracking or versioning software

Gah. A version control system, even if it is a weenie one like MS VSS, is one of the basic things separates amateur coding for fun from professional software development.

"Source control is like flossing - you don't have to floss *all* your teeth - just the ones you want to keep." - Dave Scofield, Borland

I had to write my own system

You shouldn't need to write anything - you just need to get the hardware and time to install subversion and bugzilla

As long as the basic functionality of taking the bug description (using a form) is not the problem, where is the conundrum? Here is a link where you can submit Bugzilla bugs.

I will probably get modded flamebait, but I agree.

I just went throught the process of adding Bugzilla to my installation of Fedora Core 3. I run Fedora because that is the default Linux installed by my provider and anything else would more than double my costs. I just checked the LSB Certified Distribution List, and sure enough Fedora is not on it. I tried upgrading my system using Yum, but the versions installed with Yum were not current enough for my purposes. Every piece of source I had to download to get Bugzilla installed had to be configured with a switch pointing to a non-standard install directory.

This really surprised me, because the LSB has been around for a long time. I thought all major distributions had become compliant several releases ago. I especially expected Fedora, which many people consider the standard for Linux, to be compliant.

I use a paper diary and my PDA (which has got an alarm!) for appointments and regularly occuring tasks.

My todo lists are little pieces of paper that end up in the bin or large sheets that I store so that I have a 'history'.

For some time now, I have been thinking of employing Bugzilla for tracking tasks though. It is the only program I know that has all the basic functionally for this job, but unfortunately its interface leaves much to be desired.

Bugzilla does exactly that and is what I use at work and at home, though the proposed and actual start/end dates may have to take the form of "version," "milestone," "keywords," or a combination of those. Categorization can occur through a combination of "project," "component," "version," and/or "keywords."

The Bugzilla web site exists at: http://www.bugzilla.org/

Maybe Bugzilla (http://www.bugzilla.org/ can do the trick for you. It's free and it has Email integration. Also I think SuSE had a System like that based on a News Server which also means platform independent offline support.

it's free, available here: http://bugzilla.org/ it's not exactly designed for your specific task (it's primarily aimed at quality control / bug tracking) but shouldn't be hard to adopt for your purposes.

http://www.bugzilla.org/ may work for you, depending on the complexity and requirements of features you need.

You could probably use bugzilla (http://www.bugzilla.org/). It was originally meant for tracking bugs, but it is flexible enough to do what you want. Assign each computer a bug which gets a unique number and lets you add timestamped comments and attachments at will.

-David

Great!

Now when are they going to be switching from Bugzilla to Trac?

(insert ha-ha-only-serious-cos-Bugzilla-scares-me smiley here)

Strictly, it's not Mozilla.org alone, and it's not Bugzilla alone either. Out of the box, the Bugzilla system does not block access from Referer: http://slashdot.org/* (for example see GNOME Bugzilla), but the specific instance of Bugzilla on mozilla.org does.

Err, I thought the test site had been landfill.bugzilla.org?

So as to avoid, you know, totally screwing with the Mozilla (+ bugzilla, etc.) bug database if stuff breaks? Granted, Mozilla does use really up-to-date installations of bugzilla...

In fact, b.m.o seems to be on 2.19+ now (according to the banner up top)...

[NB I'm just an interested bystander]

Bugzilla is a "Defect Tracking System" or "Bug-Tracking System". Defect Tracking Systems allow individual or groups of developers to keep track of outstanding bugs in their product effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being "free", Bugzilla has many features its expensive counterparts lack. Consequently, Bugzilla has quickly become a favorite of hundreds of organizations across the globe.

January 15 lists two entries ... talk about last minute programming!
Gamercentric.com - GAMING HEAVEN

and would love to implement Bugzilla for issue tracking but statements like this - 'Making Bugzilla work on Windows is still a painful processes.' in the OS-Specific installation notes don't make it seem reasonable.

A better set of instructions to use:

http://www.bugzilla.org/docs/win32install.html

It's really as simple as following the instructions to get it up and running with the standard configuration. I setup Bugzilla for our project team under Windows and it was a relative snap, much easier than I expected.

Of course, then came the requests to modify Bugzilla to change states and various things...

Just went over and looked at bugzilla.org. On the download page it says.

Windows users: It is now possible to install Bugzilla on Windows with very little if any modification to Bugzilla itself. See Byron Jones' Bugzilla Installation Guide for Windows for instructions.

I've set up bugzilla on windows following this tutorial and it works quite well.

Gerv, who works for mozilla/bugzilla, already went through this, and found several ways around google's hackery. He then went and summarized the multiple ways to do it in good browsers.

Heh, maybe that steam blown had a bit to do with all the misinformation and stricken refusal of honest dialogue between our (ONLY TWO!) candidates.

Thanks for staying with me.

You need to buy a copy of the Pragmatic Programmer's starter kit

The third book in the series is about project automation, where they teach you how to repeat in a controlled manner all the stuff you learned in the first two books. The basics:

1) Write unit tests before writing your methods
2) Your unit tests should follow the inheritance tree of the classes under test to avoid duplicate test code.
3) Write a vertical "slice" of your application first (all the layers, none of the functionality). This will prove out communications and give the QA people something to work with while you flesh out the app.
4) Build & unit test nightly. Any build or unit-test errors need to be fixed the next day, and no later.
5) Release to QA as often as things get semi-stable, and when they have time to test.
6) Try not to ship with any known bugs. How do you know if you've got bugs? Your unit tests, integration tests, QA tools, and end-users tell you via a bug-tracking tool like BugZilla or FogBugz

Do we do all this at my current employer? No. But we're working towards it.

Chip H.

It really depends on the sorts of tasks you are handling. If you are, for example, a builder then you will have a critical path and (hopefully ;-) strict deadlines. For something like this a calendar based task scheduler is fine. Things like KOrganizer or Plans could be used.

If there is a great number of tasks with no critical path, for example a call center, then you will want something a little more complicated. You'll need to be able to log a task quickly, give it an urgency, tie it back to a particular caller, be able to assign it, maybe even have a searchable knowledge base. For this area things like OTRS are great.

Then you could be a developer, where critical paths vary daily and tasks need to be assigned to specific modules and versions. The obvious choice here is bugzilla

Desktop or web-based is also a consideration. You may require access from multiple locations; maybe you are an off-site engineer; so that needs to be taken into consideration too.

Very often OSS projects use Bugzilla to track problems and requests for enhancements. To bugzilla, the fundamental unit (whether it's a defect or an RFE) is called a Bug.

Therefore, when they call it "Bug 9399", they are just referring to the entry in bugzilla with that number.

They are only using one of the most widely used bug tracking systems, especially for open source projects.

If I can get a large organization of mostly non-technical people (the National Office, that is, not the entire association -- yet!) to learn and use Bugzilla with little to no pain, then I have faith that a well-dispositioned and patient Slashdot user can certainly figure it out in a few minutes.

If that's his point he's not looking very hard.

While there are a few others listed here, such as this little one, many applications do require customization though typically they aren't bare generic web services like Apache.

PeopleSoft don't sell pre-made applications that require no configuration changes, and document creators don't write your content, so expecting that open source project should is highly unrealistic.

Your city has its own Bugzilla?

Cool...

If you don't have those tools in place at your company, and you want to telecommute - I'd suggest putting them in place *first*, getting everyone using them, then try asking your boss. You can point out, at that point, that the communication is the same either way. Otherwise, standard telecommuting really does hurt teams if they can't communicate as well.

• RTFM
• SAFP (send a fucking patch)
• GBTWN (go back to windows noob)
• Use lynx
• WLHCC (whiny luser who can't code)
• Goat rimmer
• 
  
  After about 50 flames i decided to do "rpm -e mozillabird" and went back to using Opera 7 for gnu/hurd, a nicely crafted browser that is worth the $39.

For whatever reason, this version of Safari, as well as v.71, won't work with the cookies in Bugzilla. On two machines I've tried it on both bugzilla.mozilla.org and our own internal versions of it. Kind of annoying to work with tickets all day at work and have to keep re-logging in. Hopefully this issue has a nice workaround either on the Safari or the Bugzilla side.

I currently recommend a nightly build of Camino instead for these users. It now has a pretty nifty & flexible Google search bar finally (obligatory screenshot). I do miss the spell-as-you-type feature in Safari however.

IMO, Debbugs isn't that great either. Its major problem from my POV is the read-only web gui. Considering one of the projects on the new SF site is a GNOME front end for the BTS, I'm obviously not the only one discontent with Debbugs.

Personally I find Bugzilla far superior to Debbugs as well as the SF BTS, but the lack of an e-mail interface to Bugzilla is apparently keeping it from replacing Debbugs.

I know complaining is easy and helping out is what counts, but I don't have the resources to actually do anything about this. Thus, my complaints is all you get. Take 'em or leave 'em.

Since there is no way to "track" a bug through various stages, through resolution, many bugs, and likely many fixes also just fall through the cracks. Since XFree86.org doesn't really have any way for various distributions to share patches efficiently, or to keep track of the status of an issue, or to even find out if a bug has been fixed or not, and if so, if it is in CVS or not, distribution development tends to needlessly end up with each vendor/distro doing a lot of duplication.

Ummm, have these guys never heard of Bugzilla or what?

Seems to me that that solution would go a long way to towards fixing some of their problems.

Once article foo is authored, submitted, formally reviewed and then approved is it actually put on the production news site.

OK, then use Bugzilla, Bonsai, and the rest of Mozilla developer tools. Giving the power to check-in only to 'reviewers' (those with the power to super-review) and to 'drivers' (those with the power to approve) solves much of that.

They say they are using a new source code control system with "acquired technology" , apparently because the previous version (which I'm assuming is SourceSafe) wasn't up to the task. I'd like more details please ... we are considering ditching a very old version of PVCS where I work. Bitkeeper won't do it, and CVS + Bugzilla isn't a solution.

Ehm, could you explain to us what kind of leverage IBM has over open source projects? If I were the administrator of an open source project and IBM would come by and tell me to switch databases I'd tell them to go mind their own business, thank you. And according to the Bugzilla installation manual it uses MySQL, not Postgres or DB/2. Also, Red Hat still maintains Red Hat Database as evidenced by the README on their ftp and you can still download it from the same place. And if you look at the SRPMs of Advanced Server 2.1 you'll note that Red Hat ships Postgres with AS2.1.

So, care to give us some supporting evidence?