783549 - (external-psm) Add a configure option to allow the use of an external PSM (overriding mozilla/security/manager)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Kai Engert [:KaiE:]]

I propose that comm-central uses a fork of directory mozilla/security/manager

We should have a configure option that disables this directory, and allows applications such as Thunderbird to instead build their own copy (such as the fork contained in comm-central).

Comment 1

[Kai Engert [:KaiE:]]

Attachment: patch v1

Comment 2

[Mike Hommey [:glandium] OoO until Dec 30]

Comment on attachment 652815 [details] [diff] [review]
patch v1

Please don't add a configure option for that. Worst case, just make it an AC_SUBST, and define the variable before calling configure. We don't need to cruft configure with temporary stuff.

That being said, why not simply disable psm with --disable-crypto, if that still works (if it doesn't, then there's bug to file to either fix it, or remove it). That still allows you to add psm in c-c.

Last but not least, I don't understand how doing it in c-c makes the situation any better. The schedule and release process is the same on both ends, it should be about as problematic (or not) in both cases. If you can't close in on a fix for gecko for FF 17, why can you for TB 17? If you really have concerns about breaking FF when fixing TB, then why not fix under #ifdef MOZ_THUNDERBIRD knobs? It wouldn't be a first, and would certainly not be as awful as forking PSM.

Comment 3

[Kai Engert [:KaiE:]]

> We don't need to cruft configure with temporary stuff.

I don't intend this fork to be temporary.


> Last but not least, I don't understand how doing it in c-c makes the
> situation any better. The schedule and release process is the same on both
> ends, it should be about as problematic (or not) in both cases. If you can't
> close in on a fix for gecko for FF 17, why can you for TB 17?

Because Thunderbird can have its own rules, because I need Thunderbird specific code, and I can't add Thunderbird specific code as long as it's shared code.


> If you really have concerns about breaking FF when fixing TB, 

I don't have concerns about breaking FF.

FF changes already broke TB, and I'm trying to undo that.

But I couldn't find an approach that is acceptable to FF people, I don't see a solution for shared code that I'm able to get done on my own, and nobody is helping (as in writing code) to get it done in time for TB 17.


> then why not fix under
> #ifdef MOZ_THUNDERBIRD knobs? It wouldn't be a first, and would certainly
> not be as awful as forking PSM.

Would work for me, if people really allow it. Although it should be #ifndef MOZ_FIREFOX (in order to cover other applications like SeaMonkey, too, and all other applications that want error reporting in their app).

But I don't expect this approach to work, I already predict Brian complaining that code becomes too unreadable. 


> Last but not least, I don't understand how doing it in c-c makes the
> situation any better.

c-c can have its own rules and doesn't need to care about preferences of FF developers.

Comment 4

[Ben Bucksch (:BenB)]

> > #ifdef

> Would work for me, if people really allow it. But I don't expect this approach to work,
> I already predict Brian complaining that code becomes too unreadable. 

Can you ask Brian first?

Comment 5

[Kai Engert [:KaiE:]]

(In reply to Ben Bucksch (:BenB) from comment #4)
> 
> Can you ask Brian first?

futile

Comment 6

[Kai Engert [:KaiE:]]

(In reply to Mike Hommey [:glandium] from comment #2)
> 
> That being said, why not simply disable psm with --disable-crypto, 

I'm OK with removing the old --disable-crypto code, BUT


> That still allows you to add psm in c-c.

I don't see how that would work. Building mozilla-central requires the interfaces that are contained in PSM.

If you argue that mozilla-central should build with thinking "there is no PSM", then I don't understand how it would find the external files from the external PSM.

Comment 7

[Mike Hommey [:glandium] OoO until Dec 30]

The important part was "if that still works (if it doesn't, then there's bug to file to either fix it, or remove it)". You're basically saying --disable-crypto doesn't work anymore. Then it should go away.

Comment 8

[Kai Engert [:KaiE:]]

Mike, do you still think we should avoid a configure option and require the use of an environment variable? If yes, I might make a new patch.

Comment 9

[Kai Engert [:KaiE:]]

(In reply to Mike Hommey [:glandium] from comment #7)
> You're basically saying
> --disable-crypto doesn't work anymore. Then it should go away.

I've filed bug 784628 for that work.

Comment 10

[Mike Hommey [:glandium] OoO until Dec 30]

I still think forking psm is wrong

Comment 11

[Kai Engert [:KaiE:]]

(In reply to Mike Hommey [:glandium] from comment #10)
> I still think forking psm is wrong

me too, but I don't see another solution to keep Thunderbird functonality alive.

Comment 12

[Mike Hommey [:glandium] OoO until Dec 30]

(In reply to Kai Engert (:kaie) from comment #11)
> (In reply to Mike Hommey [:glandium] from comment #10)
> > I still think forking psm is wrong
> 
> me too, but I don't see another solution to keep Thunderbird functonality
> alive.

I gave you one on irc. That you don't want to do it or don't have time for it is not the same thing as having no other solution.

Comment 13

[Ben Bucksch (:BenB)]

> You're basically saying --disable-crypto doesn't work anymore.

No, he's saying that the option does exactly what it says: If you build with that option, you get a Firefox that can't do SSL. The reason for that option is export restrictions: Under US law, if you distribute SSL, you're a weapons of mass destruction dealer (not kidding) and need to be registered.

Comment 14

[Ben Bucksch (:BenB)]

> > I don't see another solution
> I gave you one on irc.

Could you please also state it here?

Comment 15

[Mike Hommey [:glandium] OoO until Dec 30]

(In reply to Ben Bucksch (:BenB) from comment #13)
> > You're basically saying --disable-crypto doesn't work anymore.
> 
> No, he's saying that the option does exactly what it says: If you build with
> that option, you get a Firefox that can't do SSL. The reason for that option
> is export restrictions: Under US law, if you distribute SSL, you're a
> weapons of mass destruction dealer (not kidding) and need to be registered.

Then a psm can be built separately, and linked like other c-c components.

(In reply to Ben Bucksch (:BenB) from comment #14)
> > > I don't see another solution
> > I gave you one on irc.
> 
> Could you please also state it here?

It boils down to having opt-in nsIBadCertListener and nsISLLErrorListener generic implementations somewhere in toolkit.

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I suggest we WONTFIX this.

Kai, please correct me if I am mistaken, but I think you are proposing to fork PSM in comm-central because you expect that the set of people working on the forked version will change, or that the review policies for the forked version will be more lenient.

I do not think either of those things is the case. All the PSM peers would still be expected to maintain the forked version. And, if anything, the patch acceptance requirements for the forked version would get *more* stringent, not less.

At some point in the future, I hope that the Thunderbird product has a huge group of contributors and I wouldn't be surprised if at some point those contributors decided "Firefox guys are holding us back and we'd rather do the work without them." But, we're far from the point now.

Comment 17

[Ben Bucksch (:BenB)]

In reply to comment 15:
See bug 784628.

In reply to comment 16:
bsmith, UNCONFIRMED is for bugs from end users that may be of low quality. No bug reported by a developer should ever be unconfirmed.

I am on record above to have considered this fork overkill.
But given that even patches (!) from TB authors might not be accepted, if Firefox people consider it unnecessary for Firefox (but TB), not even within a #ifdef (!), you're basically *forcing* a fork. I can now see where Kai is coming from.

Comment 18

[Ben Bucksch (:BenB)]

Kai, another option is to fork all of Mozilla.

Comment 19

[Kai Engert [:KaiE:]]

I'm no longer interested to spend time on this task.
Feel free to do with this bug report what you want.
Good luck.