<i>> Will the DB raise an exception? Will it crash? No – It automatically truncates the data so it fits the column size.</i><p>If you write software, never be "helpful" and try to fix problems with input data you can't handle. You have no idea whether the fix you have in mind is going to be appropriate in all situations and there is no guarantee that your users are going to acknowledge the warning you might (or might not) issue in that case (case in point: MySQL does fire warnings, but many libraries don't even expose them to the user, so even if they wanted to check for warnings after every statement, they couldn't)<p>"Fixing" broken input data is nothing but actually corrupting data because after the fact there is no way to know what the original was, nor is there a way to know whether the "fixed" data was actually fixed or whether it has been that way to begin with.<p>If you are in a position where you can't do something based on the input data, then <i>blow up</i>. That way you help users to avoid ever having to deal with corrupted data (or all their private bugs exposed to the public like what happened here)
I never understood why people use MySQL for anything where correctness is important. The auto-truncaction is only one of many nasty surprises.<p>Did you know that auto-truncation also kicks in if your columns values are small, but you run a CONCAT on them? That was a nasty surprise when a generated a CSV line on DB side, which by bad luck was truncated immediately before a comma, so the result was correst, just the jast few items were missing. And ever looked at the handling of invalid dates? Not to mention what happens if you forgot to specify a column in your GROUP BY clause, but use it in the SELECT part ...<p>To anyone who is so brave to write their application using that database: Be sure you know all those issues and take care of them in your application. Or make sure you aren't affected by them. Or, switch to a high-quality database!<p>I switched to PostgreSQL a long time ago and never looked back. These people care about exactness, quality and clean extensibility in all directions, even user-defined index structures are possible (GIN, GIST). The problem that PostgreSQL was slower than MySQL disappeared as soon as MySQL became transaction safe with InnoDB, because it was now a fair comparison as PostgreSQL was transaction safe from the very beginning. Also, the PostgreSQL project management is one of the best I have ever seen, meeting schedules, regular commit fests, quality-driven, honest beta releases, and so on.
It is important to point out that access to security bugs (the ones that contain descriptions of unpatched vulnerabilities) is <i>not</i> automatically granted to all Mozilla employees, so simply having an @mozilla.com e-mail is not enough to get information on how to exploit Firefox.<p>It is enough to get access to potentially sensitive partner information (as can be seen from the posted screenshot), but those are usually a different class of bugs from security bugs.<p>Further, we now classify security bugs by the area of the code they affect, and give engineers access to just the areas for which they are responsible, rather than blanket access to all security bugs. This is a process that began even before the recent attacks, but we have been pushing it more aggressively in their wake.
1. This is mostly MySQL's fault for default silently truncating values longer than the requested length. Postgres and SQL Server don't do this, but that's all I tested<p>2. Lack of email validation by Bugzilla. Emails are max length 254, though this might not have been official when the code was written. See <a href="https://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address" rel="nofollow">https://stackoverflow.com/questions/386294/what-is-the-maxim...</a><p>3. Consider using an HMAC'd URL for registration email links instead of putting a token in the database, as per <a href="https://neosmart.net/blog/2015/using-hmac-signatures-to-avoid-database-writes/" rel="nofollow">https://neosmart.net/blog/2015/using-hmac-signatures-to-avoi...</a>
You know, if you're going to use this meme, you should get it right. It should be "all your <i>bug</i> are belong to us" [0]. Yes, it's ungrammatical -- that's the point!<p>[0] <a href="https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us" rel="nofollow">https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us</a>
I'm not sure which is worse: not validating your data, or silently truncating invalid data.<p>It seems that the fix [1] was to limit the length of email addresses to 127 characters. That'll do for the time being, but they really should pay more attention to database warnings. MySQL does all sorts of stupid things, but at least it tends to emit warnings when it's being stupid. Catching those warnings and turning them into exceptions should go a long way toward preventing bugs like this.<p>[1] <a href="https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=commitdiff;h=9d64d15" rel="nofollow">https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=commitdif...</a>
Incredibly interesting, and incredibly simple. Very cool stuff.<p>I do wonder... Why on earth is domain based privileges <i>ever</i> a good idea? There should be a proper roles system behind the scenes which doesn't grant privileges based on an email domain.
For anyone interested in similar issues: here you can find a report for a vulnerability in Phabricator with exactly the same cause (truncation by MySQL), and pretty much the same result: <a href="https://hackerone.com/reports/2224" rel="nofollow">https://hackerone.com/reports/2224</a><p>If Bugzilla would allow non-ASCII characters in the email address, MySQL's truncation behaviour with astral symbols (e.g. 𝌆) would probably have lead to a similar vulnerability as well. (It did so in Phabricator: <a href="https://hackerone.com/reports/2233" rel="nofollow">https://hackerone.com/reports/2233</a>)
The bug impact description is completely false.
Mozilla has "corporate confidential" bugs behind the @mozilla.com email check, but everything with a security rating is restricted to specific accounts that have been explicitly vouched for.