CyanogenMod has been due for a new issue tracker for a while now.

The existing Google Code tracker was started when we only supported 2 devices and Cyanogen was the only developer. Now we have about 150 devices and almost as many developers/maintainers, across 3 major versions of Android. There are almost 500 open issues on the tracker and nearing 7000 submitted in the last 3 years. The logcats and screenshots (and the occasional mp3 or video) attached to all the issues take over a gigabyte of space, and each increase in that quota has to be asked for manually. Google recently silently removed the RSS feed for all project updates, making issue tracking a bit harder for me.

The last two points there indicate the need for our own hosted solution. As several project members have worked with it before, JIRA was chosen. They provide a free licence for open-source projects (just like Google Code) and provide for a much better bug submission form and overall workflow.

If you have ever submitted a bug to a bugzilla or trac issue tracker, JIRA should be easily useable. Instead of the Google Code single-textarea form that is easily blanked, there are text boxes for each piece of required data with descriptions below. The bug searching should be better than Google Code’s, and the need for me to hand-tag every issue will be reduced (if not largely eliminated). In addition, we have loaded a plugin that ties our issue tracker to gerrit, better tracking when bugs are solved.

Utkanos, our wonderful new Wiki overlord, has rewritten my (admittedly bad) “How to use the issue tracker” page both for clarity and to correspond to JIRA.

But, and this is a big ‘but’, there are no pre-existing ways to transfer Google Code issues en-masse to JIRA. JIRA supports importing from several other trackers, as well as CSV files, but not Google Code. Meanwhile, Google Code doesn’t have any easy export options (the CSV download offered on the main issue list is only the summary/tags, not the complete text and comments) and the Google Data (gdata) XML interface can pull either the initial submitted report for all issues or comments for one. I haven’t found any good xml-to-csv converters that can handle the data, and writing one by hand has proved problematic at best.

So we will need you, the community, to re-submit your bugs to JIRA. For me to manually copy/paste everything by hand would be hours, if not days, of work. For each one of you that has submitted a bug or enhancement request to move your report to JIRA should only take a few moments.

This blog post will coincide with a bulk update of all open issues (except ‘shouldbefixed’ ones already handled). I would request that only the original submitter copy their issue into the new tracker. When doing so, they should include a link back to the original googlecode submission so I can close it. Alternatively, a link on googlecode to the new JIRA bug will suffice.

As of right now, new issues will NOT be accepted on the Google Code tracker, users should begin submitting bug reports to the JIRA instance at jira.cyanogenmod.org. Existing issues will be closed as they are moved to JIRA. In a couple weeks, I will close any remaining issues on the Google Code tracker. After that point, anything reported on JIRA will be treated as a new issue, and the google code tracker will be closed and shut down.

[An added bonus to the move to Jira is the ability for you as end users to better communicate what you’d like to see included in CyanogenMod. A new form and tag for ‘feature request’ has been added. As with bug submissions, you should search to see if your request or one similar to it has already been submitted. Duplicates, or perceived duplicates, will be merged. Please understand, unlike bugs (where we shipped something in a broken state) we are under no such obligation to fulfill requests. The sheer number of you out there compared to those available to code instantly eliminates our ability to fulfill every request. That said, if we spot a good idea that also interests us (and that’s the key stipulation here), we will work towards it.]

This has and will be a lot of work for everyone, but ultimately we will have complete control of our bug tracker and hopefully a better experience for users and developers going forward.

-PsychoI3oy, your CyanogenMod BugMonkey

Many of you may not give it a second glance, but among all the furor and concern about permissions requested by market apps and privacy, all Custom ROMs (CyanogenMod included) ship with one major security risk — root!

We have been struggling with how to handle this for quite a bit, and took a first step with the first public CyanogenMod 9 alpha builds, by disabling the previously-default root access over USB. You can still get adb root access by running “adb root” in terminal, should you ever need it.

We recently merged 3 patches into CyanogenMod 9, to further address this: http://goo.gl/eCjDV http://goo.gl/oWAFI and http://goo.gl/34vai.

What follows is an explanation of the changes, how they affect you and our reasoning behind them.

What do the patches do?
They disable root selectively and in a configurable way. Users will be able to configure their exposure to root as:

• Disabled
• Enabled for ADB only
• Enabled for Apps only
• Enabled for both

How does this change affect the usage of your device, and root apps you have installed?
On a default CyanogenMod installation, root usage will have to be explicitly enabled by the user. This means that the user is fully aware that any application that uses root may perform actions that could compromise security, stability and data integrity. Once enabled, the process mirrors that of the current process, apps that request root will be flagged by the SuperUser.apk and the user will have to grant selective access.

Why the change?
At CyanogenMod, security has always been one of our primary concerns, however, we were hesitant to make a change that might disrupt the current root ecosystem. With CyanogenMod 9 we have the opportunity to do things better, whether its the code in the OS, UI/UX, or security – we are taking this time to do things with a fresh approach.

Shipping root enabled by default to 1,000,000+ devices was a gaping hole. With these changes we believe we have reached a compromise that allows enthusiasts to keep using root if they so desire but also provide a good level of security to the majority of users.

What concerns remain?
Many of you reading this are savvy enough to note a remaining hole in this approach – recovery and unlocked bootloaders. The bootloaders are out of our hands, there is little to nothing we can do on that front.

Regarding recovery – with unlocked bootloaders, a malicious user could just flash a new recovery image (without any potential security we could apply) or just dump the data partition. This however, requires physical access to the device. As such, the security standards for this are highly reliant on you, the device owner. Data encryption is available in ICS to safeguard your data. (Warning for emmc only users – encrypted /data means recovery will be non-functional.)

The onus is on you to secure your device; take care of your possessions, and this risk is minimal. Always make sure you take devices out of your car before you go into the mall and remove them from pockets before washing laundry. Common sense is a basic security tool.

But Why?
We honestly believe there are limited uses for root on CyanogenMod, and none that warrant shipping the OS defaulted to unsecured.

Every good open source software project grows. With that growth, it sometimes becomes difficult to communicate with people within that project. This is true for the CyanogenMod project as well. With our continued growth, change is coming as well. A major change is to make it easier for outside developers to communicate with the CyanogenMod project.

This is where I, and this blog post, come into play. Are you maintaining a device that is not currently maintained by the CM team? Do you wish for that device to be added to the list with your support? Have you found a vulnerability that you discovered that needs to be disclosed? Is there a problem with code used that needs attention? There is now a face for you to communicate with to get these things taken care of.

I’ve been in the background of the CyanogenMod project for just over two years now. With the knowledge I’ve gained, I am now taking on the roll of making it easier for outside developers to work within the project. This change will help us to continue and grow as the number one aftermarket Android distribution. Please do not read this as a new contact for bug reports or feature requests. Bugs and features are to be reported on the CyanogenMod bug tracker. Code submissions will still be handled through our gerrit instance. This new contact avenue is to assist the community in ways previously described.

You can contact me via email at devrel _at_ cyanogenmod _dot_ com. I look forward to getting the ball rolling on whatever needs to be taken care of.

Here are the currently available resources for the community:
CyanogenMod Code Review
CyanogenMod Bug / Issue Tracker
CyanogenMod Forum
CyanogenMod Wiki

*Edit* Please do not send device requests. If you want to add a device to CyanogenMod and are going to do the work on it, this would be your contact avenue. Please keep requests to the Issue Tracker.

This avenue is also for questions about development process or submission guidelines. CyanogenMod does not want to exclude anyone from the development process. We want to give you as much help as possible when adding your work to ours.