[Tails-dev] Getting the Icedove patches merged upstream

Üzenet törlése

Válasz az üzenetre
Szerző: anonym
Dátum:  
Címzett: The T(A)ILS public development discussion list
CC: sukhbir.in, Jacob Appelbaum, tagnaq
Tárgy: [Tails-dev] Getting the Icedove patches merged upstream
Hi,

I'm gonna use this thread as my personal TODO list, and as a general
report on my progress so all interested parties can follow it. Note that
I've CC:ed the TorBirdy people (hopefully I didn't forget anyone), who
may have some interest in this effort.

So the plan to get the secure autoconfig patches [1] merged upstream is
as follows:

    1. Rebase patches against current Debian packaging.
    2. Check that patches applies on upstream mercurial.
    3. Test against upstream mercurial.
    4. Send a draft of the upstream merge proposal here for feedback.
    5. Send proposal to upstream, possibly in Mozilla bug #664633 [2].


In this thread I'm gonna work towards 4, and ultimately 5, but first I'm
gonna talk about about 1-3 which I've already done.

[1] https://tails.boum.org/todo/Return_of_Icedove__63__/#index6h2 and
https://lists.torproject.org/pipermail/tor-talk/2012-May/024163.html
(patches are posted in the latter for your convenience since the git
repo doesn't have gitweb)
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=664633

# 1. Rebase patches against current Debian packaging.

The patches apply cleanly against current git [3]. However, its latest
included version is icedove 10.0.3-2, but 11.0-1 has been released (in
experimental) since then. Is this just a forgotten git push by the
package maintainer, or have I missed something? I thought I should ask
you Debian pros before I bother him.

[3] http://git.debian.org/?p=pkg-mozilla/icedove.git;a=summary

# 2. Check that patches applies on upstream mercurial.

[First of all, I'm happy we're not using mercurial......]

The patches kinda apply cleanly to current trunk [4]. The only relevant
change I made was to make autoconfig not try SSL/TLS for POP/IMAP/SMTP,
something which upstream did in changeset 69177e1f55f4 [5] supposedly
due to Mozilla bug #721369 [6]. Just to be clear: now the prober only
tries STARTTLS among the secure protocols, not SSL/TLS. What makes this
even more baffling than it is in itself is that some lines up they have
a //TODO about preferring SSL/TLS over STARTTLS. WTF? I have to inquire
about this because I don't get it. The patch that was attached to the
bug did not include this change, but it slipped through in the commit
any way. Hopefully it's a mistake because the merger was testing something.

One good thing is that current trunk has a fix for certificate errors
(now you can discard or add an exception) that I had to patch around
(previously it just failed), so now I can drop one of the patches (the
most dubious one! :)).

[4] http://hg.mozilla.org/comm-central/
[5] http://hg.mozilla.org/comm-central/rev/69177e1f55f4
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=721369

# 3. Test against upstream mercurial.

Works just as intended (modulo SSL/TLS probing). For those interested,
here's a screenshot of how the GUI looks:

    http://oi49.tinypic.com/35iavew.jpg


The only added control is the "Only use secure protocols" checkbox.

# 4. Send a draft of the upstream merge proposal here for feedback.

I'll write something up once the issues in 1 and 2 are resolved. Any
pointers on how to do this with maximum chance of success is highly
welcome (we all know that getting patches accepted is pretty hard when
dealing with Mozilla).

Cheers!