The 3.3 release is getting closer, as you can probably tell from the activity in the bug tracker and in the git repository. While the 3.3 development version is not ready for public testing yet, it’s time to tell you about another new, cool feature coming in 3.3:
Markdown syntax support!
We are currently making a few improvements to the forum, which will help make using the forum a better experience.
First of all, marking topics as solved
A feature that is often on support forums is a ‘mark as solved’ function. When your problem is solved, you can let everyone know what post in the thread solved the issue, and this brings many benefits:
Threads marked as solved get a little green tick wherever they are shown, and clicking this tick jumps straight to the solution.
We have turned this on in our ‘problem-solving’ forums, though we can always add it to more if necessary.
To mark a thread as solved, just click the little tick. Please note that only you and the moderators/administrators can do this, so please be vigilant. The tick is found near the quote button:
And secondly, logging in with OpenID
Having multiple accounts everywhere is a pain. One of the new features in The Bug Genie 3.2 is OpenID support, and it would be a little contradictory if we supported it on our tracker but not the forums! With this in mind, once the theme is fixed, OpenID support will be added to the login page, so you don’t have to create yet another account to make use of the forums.
This is now available! You can link your existing accounts to an OpenID if you want, go to your user control panel and choose Profile.
As discussed earlier on this blog, changes in The Bug Genie 3.2 to improve our support of Unicode may result in some data being mangled after upgrading to The Bug Genie 3.2 The technical reasons behind this have been explained before, this post is just to give a brief overview on what happens and how to fix it, for those of you upgrading from previous releases.
Do I need this?
If you use PostgreSQL, or are performing a fresh installation, this is not necessary. In addition, this may not be necessary when you upgrade from a prior release, especially if you do not use special characters.
The fix, if necessary, should be applied as soon as possible after upgrading, do not perform the fix before installing the 3.2 files. You may, if you wish, install the 3.2 files, run the upgrade script, and then explore your installation to see if the fix is necessary – if you see mangled characters in any text field then you will need to apply it. Do not adjust any field before applying the fix, as any new special characters will be destroyed.
If there are only a few to correct, you can always do this by hand, but the fixes below are more efficient if there are many issues.
The problem
We did not correctly handle the connection to the database in The Bug Genie 3.0 and 3.1. This meant there were occasional issues with special characters being mangled or lost in various places, such as fields in an issue. The connection opened to the server was not Unicode, and therefore the data was not stored in a Unicode fashion, leading to problems.
In The Bug Genie 3.2, we do create a proper Unicode connection, meaning the mangled data will now be shown as-is. While there were cases previously where the data was correctly shown, by ensuring the problem is resolved properly now, we avoid potential issues in the future.
The solution
There are two solutions available. If necessary, you should apply one before upgrading, but you can always check afterwards to see if a fix is necessary. You can apply the fix after upgrading as long as you do not add any Unicode characters to the database beforehand, as these will be destroyed by the fix.
If you have command line access to the server:
The following commands will resolve the issue. A database dump is made in the non-UTF format we used to use in The Bug Genie, this is then restored in the correct format. The database is recreated also, to ensure it is in UTF format, so please make sure you have the right permissions. We assume a database called thebuggenie, and a user called root. Change these if necessary.
mysqldump -h localhost --user=root -p --default-character-set=latin1 -c --insert-ignore --skip-set-charset -r dump.sql thebuggenie
mysql --user=root -p --execute="DROP DATABASE thebuggenie; CREATE DATABASE thebuggenie CHARACTER SET utf8 COLLATE utf8_general_ci;"
mysql --user=root --max_allowed_packet=16M -p --default-character-set=utf8 thebuggenie < dump.sql
If you don’t have command line access to server, but you do have phpMyAdmin:
You can also apply the fix using phpMyAdmin. The trick is to change the connection collation, which can be done via box on the front page
This should be set to latin1 when taking the database export (leave the file as UTF-8), then set back to utf8_general_ci when recreating the database and importing. The database collation should be set to utf8_general_ci, and this can be set via box to the right of the database name field:
Please remember to dump just the data of the database, and not the structure and data. This can be done by selecting a choice when exporting, you may have to choose an option ‘Custom – display all possible options’ first.
Note: The timezone fixer in the initial release of The Bug Genie 3.2 may not work if you have a huge number of issues and comments, as the process is very intensive. We will be performing further changes in the future, and a CLI task to perform this operation will be in a subsequent release of The Bug Genie 3.2. We therefore do not recommend using this tool if you have over 500 issues.
It’s a well known fact that The Bug Genie’s timezone support doesn’t work right in 3.0 and 3.1. One of the more serious bugs was with how timestamps were stored: they were stored in the timezone of the user who caused the action (i.e. opened the issue), and then adjusted to the timezone of the user viewing the thing which involved at time. Therefore, if you both created and viewed an issue which was opened at 03:00UTC, and your timezone is +3, it would be stored as 06:00, and you would see it opened as 09:00.
The cause of this is fixed in The Bug Genie 3.2, and new timestamps will be stored as UTC, so only your timezone offset is applied. This will fix your timezone problems for new issues, comments and so on, but not for previous ones. This is why the upgrade script gives you the option of fixing your timezones.
How does it work?
The script, if you ask it to, will go through every item in the database which involves a timestamp and will remove the offset coded into the database.
We look at the timezone of the user who caused the action (if he has one set, and it isn’t ‘sys’), and if one can’t be found we use the system timezone instead. Also note, if the guest user made a change, then the system timezone will also be used. If the outcome of this is UTC, then nothing needs to be done as there will be no error.
If, on the other hand, it is not UTC, then some work needs to be done. We can then perform the offset change on that timestamp, and this should in the majority of cases lead to the correct result. The advantage of this way is we catch cases where the user timezone is different to the system timezone.
There may still be some times which are incorrect, for example if either the user or system timezone had ever been something different prior to what it is during the upgrade, or if the user who caused the change cannot be identified (this is the case in the builds and milestones table). There is nothing that can be done in these cases to improve the accuracy, as we are suffering from either a lack of history of timestamp settings or users who performed actions, and so we give the option of disabling this conversion. You can also turn it off if you just want your timestamps left alone.
What will it convert?
Times will be corrected in the following tables:
To get you even more excited for the upcoming 3.2 release, we wanted to share a few highlights from all the work being done on the next version. We’ve ripped into so many pieces around the entire system, there is hardly anything left untouched – an exciting and scary feeling for a point release (3.1 -> 3.2). We could just as well have pulled “a Mozilla” and called it 3.5, but for the sake of our own (and your) sanity, 3.2 it is 🙂
So, what are all these highlights, I hear you whisper in the corners. Read on to get a glimpse!
One of the main areas of focus for 3.2 is improvements in usability and general appearance. We’ve added some new style elements, and are going through all the different areas of The Bug Genie, applying the new style elements where appropriate. These new style elements go far beyond mere looks, however, and whenever we can, we do a functional review of the area we’re working on and try to find things to improve. One of the latest pages to see some style and usability improvements is the issue details page. This page is usually where you spend most of your time, so anything we can do to help here is time well spent. Here is a summary of the changes we’ve made to this page.
Update: After being confronted with the details of this blog post, a retraction was posted on twitter (https://twitter.com/#!/vuln_lab/status/98858850534424576), but the security notice is still available on their website, and the description still mentions 3.0.1, even though the header has now been changed to 2.0.8. Please note that version 2.0.8 is severely out of date and was first released in mid-2009. The security notice still has all the errors below, and is still not considered valid by anyone on the bug genie team.
Hey everyone. This blog post was created to clear up any confusion around a false security notice posted by a pretend security lab on twitter. The complete security notice can be seen here: http://www.vulnerability-lab.com/get_content.php?id=45. I will explain why this security notice is false in a few seconds, but first I want to clarify something.
Real security companies looking for bugs, errors and security issues in code work closely together with vendors and projects to make sure the details are correct, and to – when possible – coordinate disclosure so that there can be a fixed version available at the time of publication. Neither of these things happened in this case, and in addition to that, there are several factual errors and inconsistencies in the report.
Security notices like these serves no purpose. They don’t help. They don’t shed any light on anything. Whoever is behind this notice has not given us any chance to fix, confirm or deny the issue described, and no proof-of-concept code has been provided. The issue they claim to have found is not shown in their security notice.
While no software is perfect, you should not take all security notices for granted. Responsible security labs work together with vendors so a fix can be provided together with the disclosure, and in any case provides details about security issues to the vendor in question.
There is nothing to see here. Move along.
As a small heads up for those of you who don’t use Apache, I’d like to bring your attention to our library of rewrite rules. We are often asked by users for help setting up URL Rewriting (which The Bug Genie 3 requires) with their server, and this post is there to point out what documentation we have.
Just right now, documentation for IIS 7 and later was added, meaning we now cover the most popular platforms. However are work is not yet done, with documentation for IIS 6 still unwritten (IIS 6 docs now out!), and apparently issues with the nginx one; on top of no doubt other servers that you wonderful users want to use The Bug Genie on (let us know if there is one you need!) Regardless, we currently support:
Further documentation, as well as the above (except Apache) can always be found in the Recipes section of our documentation.
zegenie posted a short while ago regarding encoding trouble with The Bug Genie, especially those of you who use Greek or Russian alphabets. The good news is we have made some progress on this topic!
The root of the problem is to do with how The Bug Genie connects to the database. Each component has different encoding:
The last of these is the crux of the problem. On my system (as I am from Britain), the connection is latin1. This is fine for me, as I don’t need any unicode characters. However, for those of you who do, this means that unicode data is inserted into a unicode table, but is converted to something else (such as latin1) in the process.
The net result is that it will look right on the screen, but in the database it is garbage. This is fine up to the point where you start trying to do stuff with it, as there is a potential for problems to occur with JSON and other unicode-specific things, as what is in the database is not unicode (it is infact latin1 or whatever)!
An example of this is to copy some Russian text into both the Title and Issue Description fields. It will appear correctly in the Issue Description but not in the Title (it will claim it is empty).
This is easily fixed by setting the connection to use UTF-8, by placing this call on line 539 of core/B2DB/classes/B2DB.class.php:
self::getDBLink()->query('SET NAMES UTF8');
Now, all unicode data will be stored correctly in the database. However, this now results in another problem!
Any mangled Unicode data stored in the database as latin1 will be outputted as stored in the database (as no conversion is going on). This means that the mangled text in the database will be rendered to the screen. Luckily this is easily resolved by outputting a dump of the database in a latin1 connection, and then reimporting in a utf-8 connection (the nice Unicode output is obtained on the latin1 export, not the mangle that you get if you exported as UTF-8). The following code will do this, but don’t do this unless you put in the above code change:
mysqldump -h localhost --user=root -p --default-character-set=latin1 -c --insert-ignore --skip-set-charset -r dump.sql thebuggenie mysql --user=root -p --execute="DROP DATABASE thebuggenie; CREATE DATABASE thebuggenie CHARACTER SET utf8 COLLATE utf8_general_ci;" mysql --user=root --max_allowed_packet=16M -p --default-character-set=utf8 thebuggenie < dump.sql
We will be continuing to work on these encoding issues for The Bug Genie 3.2.
If you’re stuck when trying to install or use The bug Genie, remember to check the FAQ to see if a solution is available. Also, if you’re dropping by our IRC (live chat) channel and don’t get an answer, remember to check the FAQ the following days. If noone is around to answer your question, we try and add the solution to the FAQ in one of the following days.
The Bug Genie team blog 