526496 - Approved configs not published to live server

Status: RESOLVED INVALID

(Webtools :: ISPDB Server, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
1. Try to configure an account from fastmail.fm

Actual result:
1. Heuristics run
2. IMAP server is imap.fastmail.fm, SMTP server has no SSL.

Expected result:
1. Config fetched from Mozilla DB.
2. IMAP server is mail.messagingengine.com, and
   both IMAP and SMTP use STARTTLS.

Reason:
Thunderbird has the following URl as autoconfig server:
<https://live.mozillamessaging.com/autoconfig/>
That's - as far as I understand - what gozer chose, because the URL needs to be stable and working for years and decades.

However, if you go there, there are only the hand-crafted XML files that I wrote. Configs from the ispdb - even if they are approved - are not published there. (Similarly, configs which are later invalidated in ispdb should be removed from the live server.)

gozer, can you please connect the two servers? Preferably "push": As soon as a config is approved in the ispdb, it should immediately go live, so the approver can test it. Failing that, maybe an export + rsync (in the direction of your preference) would do the job.

Severity:
major. ispdb is useless without this.

Also, earlier today, I told fastmail.fm to test the config, but it's failing.

Comment 1

[Philippe M. Chiasson (:gozer)]

(In reply to comment #0)
> Reproduction:
> 1. Try to configure an account from fastmail.fm
> 
> Actual result:
> 1. Heuristics run
> 2. IMAP server is imap.fastmail.fm, SMTP server has no SSL.
> 
> Expected result:
> 1. Config fetched from Mozilla DB.
> 2. IMAP server is mail.messagingengine.com, and
>    both IMAP and SMTP use STARTTLS.
> 
> Reason:
> Thunderbird has the following URl as autoconfig server:
> <https://live.mozillamessaging.com/autoconfig/>
> That's - as far as I understand - what gozer chose, because the URL needs to be
> stable and working for years and decades.

That's correct, all in-product urls will be under live.mozillamessaging.com/[...]

> However, if you go there, there are only the hand-crafted XML files that I
> wrote.

Those are the configs checked-out from svn.mozilla.org, correct.

> Configs from the ispdb - even if they are approved - are not published
> there. (Similarly, configs which are later invalidated in ispdb should be
> removed from the live server.)

Yes, that's a known situation. The ISPDB app itself isn't even finished, and having it publishing data to live installation of Thunderbird is obviously planned for, but not yet enabled/implemented.

> gozer, can you please connect the two servers? Preferably "push": As soon as a
> config is approved in the ispdb, it should immediately go live, so the approver
> can test it. Failing that, maybe an export + rsync (in the direction of your
> preference) would do the job.

Actually, it's a bit more complicated than that. We most likely will want some level of additionnal review/auditing before data moves from ISPDB => Thunderbird. We've discussed this before while designing the ISPDB app, and it was agreed on that keeping SVN as the final repository for the live data was a good idea.

The reason for this is the possible impact to TB users if this data ever got compromised somehow. So, the current plan looks something like this:

 - Get an easy/simple way to grab all approved data from a live installation of the ispdb and generate a tree of XML files locally, like what's in svn. On a regular basis, run that export and compare with what's in SVN. If there are differences, someone files a bug, generates a patch, and asks for review. Some TB peers review and the patch lands, shortly afterwards, the change is live.

Something like that, anyways. The overall idea is to almost consider the live ISPDB data like code, process wise. The process itself isn't even finalized, and I just highlighted what I believe it was going to be.

For testing settings, I agree that there needs to be a better way. I'd suggest looking into setting up an alternate testing ispdb location that does feed live and approved ispdb configuration back to thunderbird. That way, you could have just changed your ispdb url to something else, and test your changes live directly.  That's a very good idea.

> Severity:
> major. ispdb is useless without this.

And a fact that is known.

There was a masterplan discussed for ISPDB, but I believe it's in the wiki somewhere I can't find, or else, just ended up on IRC.

I am going to start filing a few more ISPDB bugs, as well as a tracking bug, for keeping count of what needs to be done before we are ready to 'go live' with the ispdb.

Comment 2

[Ben Bucksch (:BenB)]

gozer, I don't think we need an additional level of review. The ispdb already has an approval process.

That ought to be enough. I think filing a bug and a second review based on svn diffs is overkill and will bring the whole process to a screeching halt. So far, nobody has even bothered to approve the configs in the ispdb, even though it's as easy as 2 clicks (in addition to checking it). Who's going to spend the time to file bugs, review manually, approve, check-in? I have no hope that a lengthly review process will bring us a widely-covering ISP database.

I see no chance of this whole review process to go work for a good number of ISPs before TB 3.0 release. Esp. given the release frenzy and and resulting lack of time. And I want TB 3.0 to go live with many ISPs, so that users can actually make use of the feature when they try out the brand-new TB 3.0 that hopefully the press reports about. It should work with *their* ISP.

We're now shortly before RC1. We need to test the configurations. That requires cooperation from users, as I don't have accounts for all ISPs of the world. That means the process needs to be quick and workable.

In short: Just an rsync should be fine.

Comment 3

[Ben Bucksch (:BenB)]

> The overall idea is to almost consider the live
> ISPDB data like code, process wise.

FWIW, I think it's far less sensitive. Code breach gives you access to all files and communication and keystrokes on my computer. A bad config will at worst make the email password known to an attacker - after a sophisticated phishing attack and sneaking into our ISP DB. However, current situation is that almost everybody sends email passwords in the clear. And FWIW, the heuristics we do can be tricked (with an active, but local attack) to supress SSL, too. Therefore, I agree that configs are somewhat sensitive, but a whole order of magnitude less sensitive than code.

Comment 4

[David Ascher (:davida)]

As the primary author of the ISPDB website, I'm very much not ready to have its output published live w/o review at this stage.  There are too many possible bugs which could cause really bad experiences for lots and lots of users.  Over time, as we build confidence in this software, and build test coverage, we can automate it more, but I think it's premature.  I would rather not provide ISP data for most users and fallback on port probing than put user passwords at risk.

It's unfortunate that we likely won't have time to take ISPDB to production in time for 3.0, but we can do so shortly thereafter.

Comment 5

[Ben Bucksch (:BenB)]

That's a real pity.

As said, without ISP DB, we have a much greater risk of the user being hacked/spoofed.

May I at least take those configs that are in the ISP DB and are verified, take the XML, manually correct it, and then by hand check it into SVN, so that it goes live, for at least some big, important ISPs that I have verified?

Comment 6

[David Ascher (:davida)]

I don't think any one person should be checking data in w/o some review.  So what I'd suggest is that you create patches against the SVN, get review (from gozer or me, I guess), and then check that in.  

(If it's data that other people entered and that you checked, then I suppose a 3rd person reviewing isn't necessary.  But if it's data you entered, I think a second pair of eyes should be needed, until we automate things).

Comment 7

[David Ascher (:davida)]

Can you clarify why you say that we have a greater risk of being hacked/spoofed?  Apart from the centralization concern, are there specific issues you know about w.r.t. our current isp data delivery mechanism?

Comment 8

[Ben Bucksch (:BenB)]

No, in contrary (maybe you read "without" as "with" in comment 5?), I meant that using the central database or ISP fetch, both which are delivered from fairly trusted sources and via secure means (SSL), is considerably *more* secure than the probing/heuristics. The heuristics are easy to hack: all a cracker needs to do is make the SSL and secure auth test fail, and we'll fall back to cleartext password and deliver the password into the hands of the attacker for free.
The ISP DB and ISP fetch are far more secure than that, so as far as security is concerned, the goal must be to get them online and working ASAP, for as many users as possible.

Comment 9

[Ben Bucksch (:BenB)]

(I realize that the concern here is that the DB is cracked, or the review process gamed. My assertion is that this would be harder and have a much higher risk of exposure for the hacker than the hacks that are possible without config fetch.)

Comment 10

[David Ascher (:davida)]

Ah, right, ok, I understand.  Yes, hacking the domain probing process for a single domain would likely be easier than hacking our central DB.  On the flip side, hacking the central DB would affect huge numbers of users at once.  

I think we're in agreement overall -- it's just a matter of working through the issues until we have trust in the ISPDB contribution/review/publishing process, and figuring out the right process for the decentralized fetching of configs from ISPs.

Comment 11

[Matt]

It is time to move forward with this bug.  The ISPDB is a central plank of the new account wizard, and unless the data is published on a regular schedule to the live site then the database is next to useless.  The code that uses the ISPDB data has been in production for more than a year, and I have spent most of that year supporting users who have not got correct account configurations in the https://live.mozillamessaging.com/autoconfig/ but are in fact in the ISPDB and wondering to my self what was wrong.  Now I know what is wrong.  A half completed product has been released in the wild and nothing is happening to get the updates into the live production environment.

While I have no idea of the internal workings, it is obvious that the data has to be approved. How hard would it be to automate the process and stop the automatic update if more than what is considered a safe percentage of records have been altered and seek a manual review on that occasion only?  

It would appear that your reluctance is based on hacking.  IF the data was hacked, they would not be satisfied with one or two domains, they would change all the big ones.  This would result is a statistic on change that could be used to flag a manual approval of the update.  

After a year, there should be sufficient data on changes to the database to place a fairly good metric in the process and remove the need for the one thing Mozilla has a real shortage of 'manpower'.

Comment 12

[Ben Bucksch (:BenB)]

> half completed product has been released
> nothing is happening

We have the configs for *all* domains with more than 1-2% of market share in production.

I understand that not enough for small domains, that's why work *is* happening on this bug.

> IF the data was hacked, they would not be satisfied with one or two domains,
> they would change all the big ones.

False premise. Saying that we will accept single domains to be hacked is not acceptable.

Comment 13

[Andrei Hajdukewycz [:sancus]]

This bug is just one bug. Bug 526559 is the tracking bug that contains most of the outstanding issues keeping ISPDB from being directly linked to production. That bug doesn't necessarily contain everything, either, as there are likely other issues that need to be thought about after those ones are resolved.

I'm the person currently responsible for ISPDB development. Well, actually, I'm responsible for all Mozilla Messaging web development. ISPDB is important but it doesn't always take first priority, and I inherited this project after it hadn't been worked on in quite some time, without a lot of detailed prior knowledge of Django/Python apps.

That said, it is quite possible to get isp configurations added to the live database. You need to follow the process here: https://developer.mozilla.org/en/Thunderbird/Autoconfiguration which amounts to pulling the XML configuration for the ISP you want and submitting it as a bug, and then it'll be reviewed and committed to the live database which is here: http://svn.mozilla.org/mozillamessaging.com/sites/autoconfig.mozillamessaging.com/trunk/

We regularly commit patches to this folder, several times a month at least.

Comment 14

[Andrei Hajdukewycz [:sancus]]

The current process is to pull request XML files to https://github.com/thundernest/autoconfig and there are no current plans to revive the idea of an ISPDB app, so this bug is invalid.