Closed Bug 1654950 Opened 4 years ago Closed 4 years ago

OpenPGP - Offer a configuration to not automatically attach the public key when signing

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(thunderbird_esr78 fixed, thunderbird83 fixed)

RESOLVED FIXED
84 Branch
Tracking Status
thunderbird_esr78 --- fixed
thunderbird83 --- fixed

People

(Reporter: alextogus, Assigned: KaiE)

References

()

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36 OPR/69.0.3686.77

Steps to reproduce:

When an email is PGP signed, the public key is automatically attached to the email.

Actual results:

When an email is PGP signed, the public key is automatically attached to the email.

Expected results:

The choice to attach the public key should be left to the user and be disabled by default.
It makes the emails unnecessarily heavy.

Public keys are available on key servers such as key.gnupg.net
Thunderbird should investigate this avenue of publishing keys on a key server.

Flags: needinfo?(kaie)
Status: UNCONFIRMED → NEW
Component: Preferences → Security: OpenPGP
Ever confirmed: true
Flags: needinfo?(kaie)
Product: Thunderbird → MailNews Core
Summary: OpenPGP - Signature and public key sent as an attachment → OpenPGP - Offer a configuration to disable the public key attachment when signing

Is this related (to be handled similarly) with bug 1629309 ?

(In reply to pbrandao from comment #1)

Is this related (to be handled similarly) with bug 1629309 ?

No.
This is the problem identified by Wayne Mery:
https://support.mozilla.org/en-US/questions/1299571

Same problem here: Missing an option to disable "Attach my public key" for an account/identity in general, not just disabling it for every mail manually.

Resolution of this issue is basically necessary to use the signing feature in my opinion because it's inappropriate to add attachments to every email and will confuse those who don't know what the key is for or why I've sent it to them repeatedly.

Maybe as a quick work around fix it would be possible to change that attaching of public key is switched off by default?
I think this would solve the problem for most of the affected people.

(In reply to Saulius Gurklys from comment #5)

Maybe as a quick work around fix it would be possible to change that attaching of public key is switched off by default?
I think this would solve the problem for most of the affected people.

That would be fine for me. I really don't envision any scenario where I would want or need to attach the key to every email. The existing option to attach it in the composition window should be all that's needed.

(In reply to Karl from comment #6)

(In reply to Saulius Gurklys from comment #5)

Maybe as a quick work around fix it would be possible to change that attaching of public key is switched off by default?
I think this would solve the problem for most of the affected people.

That would be fine for me. I really don't envision any scenario where I would want or need to attach the key to every email. The existing option to attach it in the composition window should be all that's needed.

Me too!
I share my keys with links, no attachments.

Even an option under the advanced config editor would be useful.

This is URGENT!

It must be possible to disable "Attaching the public key".

It must be possible to use encryption automatically whenever possible; with encryption turned on by default it must still be simple to switch to non-encrypted in case there are not enough keys. This was ok with enigmail, but with tb 78 I have to click away the warning, find the disabling thing in button or menu and then invoke sending again --- that is too much if I have to do that for each and every email! (Is there another bug report for this part?)

How shall people be convinced to use encryption if they have to go through these complications? They will (as even I do now!) turn off automatic encryption.

Indeed: bug 1644085

La seule solution que j'ai trouvé est de passer par un certificat SSL.
Thunderbird a tué PGP... Il fallait laisser vivre Enigmail !
(In reply to Michael Nüsken from comment #9)

This is URGENT!

It must be possible to disable "Attaching the public key".

It must be possible to use encryption automatically whenever possible; with encryption turned on by default it must still be simple to switch to non-encrypted in case there are not enough keys. This was ok with enigmail, but with tb 78 I have to click away the warning, find the disabling thing in button or menu and then invoke sending again --- that is too much if I have to do that for each and every email! (Is there another bug report for this part?)

How shall people be convinced to use encryption if they have to go through these complications? They will (as even I do now!) turn off automatic encryption.

The only solution I found is to use an SSL certificate (S/MIME). https://extrassl.actalis.it/portal/uapub/freemail?lang=en
Thunderbird killed PGP... It was necessary to let Enigmail live !

very sad.... We need to find another mail encryption solution now :-/ Enigmail was useful, but at the new integrated PGP solution are so much bugs and missing important features like this, that is not possible to use this in a business or enterprise environment anymore.

And even in private!

Another UI problem: external private keys & multiple identities. Thunderbird simply doesn't remember settings for secondary identities, if external PGP is configured. And external PGP is a must, because Thunderbird doesn't support smart cards and doesn't encrypt private key without master password. And master password is asked only once, at start of a program! And web of trust is not supported, too.

So, PGP is possible with new Thunderbird, but very inconvenient.

bug 1667088

I really want to be able to sign messages without attaching my key. From the recipient's point of view it adds unecessary workload. Mail clients have visual signals for "this email has an attachment" for good reason. If every email I send has a useless attachment then that signal loses its usefullness for the recipient. Instead every time I send an email they need to read the attachment list to see if I've sent a real attachment or just another copy of my key.

PLEASE this is URGENT.

Should be:
Disable attachment for attaching the public key by default.

Best solution:
Add a configuration option for choosing this.

It is REALLY annoying that any mail that I sent gets my public key attached if I do not think of disabling this again and again.

(In reply to Michael Nüsken from comment #16)

PLEASE this is URGENT.

Priority: URGENT
Severity: High

(In reply to Lev Serebryakov from comment #14)

...
https://bugzilla.mozilla.org/show_bug.cgi?id=1667088

bug NNNN format is preferred so that bugzilla autolinks - for example bug 1667088

Just noticed: it is even worse.

Situation: Disable signing for an email account. tb will not sign and not attach the public key. But then: Choose signing for a particular message.

IS: Then the "attach key" gets activated as well!!! WHY? :(((

SHOULD: Nothing else is modified.
There is an own toggle for attach key, it must not change automatically!

There is also another - privacy related - aspect to that:

Groups are using a software called schleuder which is not only a software that allows to have an encrypted mailinglist, but also comes with a feature called resending.

This allows groups to maintain one email address as a contact relay and have individuals answering mails in the name of groups. See more about it here

Now, when resending schleuder anonymizes the mail in terms of it removes signature (adds its own) and exchanges the from to the lists' address. But still it forwards all attachments to the "outside person", as you might send attachments to outsiders.

With TB 73, this now means that if senders do not explicitly pay attention to the attachment of their personal key, they accidentally reveal the actual sender of the message.
Depending on groups using that software as a gateway for answering in the name of a group this can have severe consequences. E.g. tails is known to use schleuder

See Also: → 1670767

(In reply to ng+tb from comment #20)

There is also another - privacy related - aspect to that:

This is important IMHO.

In case you didn't realize: you can turn it off per message (Security button, uncheck Attach my public key)

(In reply to Magnus Melin [:mkmelin] from comment #23)

In case you didn't realize: you can turn it off per message (Security button, uncheck Attach my public key)

It is not funny. 100 messages to mailing lists a day — 200 additional clicks. And these attached keys are useful only for new contacts, not for messages to people (and lists) with whom you communicate for 5+ years.

Another problem is, I want to sign all my messages (because it is simpler than decide what I need to sign and what could be left without signature), and this attached key looks like full-featured attach in any MUA without PGP support. People asks, what I wrote in this strange attach. Yes, these people will never check my signature, sure, but, again, it is all about my mental load (do I need sign this? Do I forget to uncheck key attachment option here?).

This has indeed lead me to turn off automatic signing because the vast majority of the people I communicate with don't use Thunderbird and aren't going to check the signature. Instead I would likely get a hundred questions asking what this is I attached and how to open it, followed by frustration that they can't find emails from me with real attachments because every single message says it has one.

Not to mention, attaching the key to the message breaks authentication. What if I sent an unsigned message and an attacker modified or spoofed it, made up a key, and signed and attached it?

This is not good and needs to be changed. I should be able to leave automatic signing on without attaching the key to every message.

(In reply to Karl from comment #25)

Not to mention, attaching the key to the message breaks authentication. What if I sent an unsigned message and an attacker modified or spoofed it, made up a key, and signed and attached it?

The signature is (hopefully) over the whole email including attachment and therefor it includes the automatically added public key. If this is not the case, please open a separate bug, but I do think this is the case.

(In reply to Karl from comment #25)

This is not good and needs to be changed. I should be able to leave automatic signing on without attaching the key to every message.
YES!

Why is this bug not assigned yet? Why does it still not have HIGH priority?

(In reply to ng+tb from comment #26)

(In reply to Karl from comment #25)

Not to mention, attaching the key to the message breaks authentication. What if I sent an unsigned message and an attacker modified or spoofed it, made up a key, and signed and attached it?

The signature is (hopefully) over the whole email including attachment and therefor it includes the automatically added public key. If this is not the case, please open a separate bug, but I do think this is the case.

It will not help if attacker adds his own key to my unsigned message as my own. It is one of the reasons to sign EVERY message. And attachment of key to every message leads to too many questions from people who knows nothing about PGP.

Sign every message: good. Attach key: useless and even bad.

I can not imagine situation when attachment of key is better than using keyserver or passing key by other means. Trust key signed by itself? Sorry, bad idea, like self-signed certificate.

And Thunderbird doesn't support web of trust now :-(

I found a quick work around fix for this issue, and as it affects more people, I've decide to share.

DISCLAIMER:

  1. I have only tested (currently using) this with TB 78.3.2 on Linux
  2. It works for me, but I do not guarantee that it'll work for you
  3. This fix will stop working after next TB update (most probably)

The fix:

  1. Close/Exit TB
  2. Backup file omni.ja (it is a ZIP file) in TB installation directory
  3. From omni.ja extract file chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js
  4. Apply this patch (or just make these 3 changes manually)
diff --git a/chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js b/chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js
--- a/chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js
+++ b/chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js
@@ -1669,7 +1669,7 @@
 
   if (!gUserTouchedAttachMyPubKey) {
     if (gSendSigned) {
-      gAttachMyPublicPGPKey = true;
+      gAttachMyPublicPGPKey = false;
     } else {
       gAttachMyPublicPGPKey = gAttachMyPublicPGPKeyInitial;
     }
@@ -1717,7 +1717,7 @@
 
   if (!gUserTouchedAttachMyPubKey) {
     if (gSendSigned) {
-      gAttachMyPublicPGPKey = true;
+      gAttachMyPublicPGPKey = false;
     } else {
       gAttachMyPublicPGPKey = gAttachMyPublicPGPKeyInitial;
     }
@@ -3798,7 +3798,7 @@
 
     // automatic changes after this line
     if (gSendSigned && gSelectedTechnologyIsPGP) {
-      gAttachMyPublicPGPKey = true;
+      // gAttachMyPublicPGPKey = true;
     }
   } else {
     // When switching the Sender identity, use the more secure setting
  1. Put patched chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js back into omni.ja
  2. Start TB and enjoy

In case something wrong restore omni.ja from backuped copy.

I am also successfully running the above patch. I made a simple script out of it to re-apply it on updated TBs: https://0xacab.org/-/snippets/905

The patch works for me on a Windows8.1. Thanks a lot!

(In reply to Saulius Gurklys from comment #29)

I found a quick work around fix for this issue, and as it affects more people, I've decide to share.

DISCLAIMER:

  1. I have only tested (currently using) this with TB 78.3.2 on Linux

seems to be working on Windows 10 (19041.572), also — thanks!

The patch works for me on Debian/Buster amd64.

I had to modify a few things, like the path (and line 11). I also don't use sudo, so the last line is modified to output the command to executed as root to actually replace the omni.ja file in system directory.

https://paste.debian.net/1167801/

Isn't this a duplicate of bug 1645514?

Anyway: see my comment #16 there about the Autocrypt header, that also gets switched on and off by the attachment option.

This script seems to no longer function.

I don't understand why it's so wrong to allow users to not send their PGP attached to every email.

(In reply to Saulius Gurklys from comment #29)

I found a quick work around fix for this issue, and as it affects more people, I've decide to share.

DISCLAIMER:

  1. I have only tested (currently using) this with TB 78.3.2 on Linux
  2. It works for me, but I do not guarantee that it'll work for you
  3. This fix will stop working after next TB update (most probably)
    ...
  4. Apply this patch (or just make these 3 changes manually)
    Well, I did that, manually, & for now still seems to work, except that updates undo the changes. So I changed the Updates option to:
    'check for updates but let me choose' so I would be aware when updates occur.
    (To me it seems a waste of storage space & probably annoying to recipients to duplicate the same attachment over & over.)
    TB 78.4.0
    Windows 20H2 (19042.572)
    31Oct2020

(In reply to Bat Manuel from comment #35)

I don't understand why it's so wrong to allow users to not send their PGP attached to every email.

Nobody rejected the request to make that a global option so far, but nobody also implemented a solution to it. So please either come up with working code that implements a solution or wait till someone picks it up. This is free software that all of you get for free (especially as in free beer). Continuously complaining will not make folks more happy/interested/... to spend their time for free software.

Although I personally think it shouldn't hurt having this attachment, I'm hearing you. For the stable 78 branch, we cannot easily introduce new UI with strings. But I think we can try to make a hidden configuration option available, which, when deliberately set by the user, doesn't automatically attach the key when signing.

Assignee: nobody → kaie
Summary: OpenPGP - Offer a configuration to disable the public key attachment when signing → OpenPGP - Offer a configuration to not automatically attach the public key when signing

(In reply to Bat Manuel from comment #35)

This script seems to no longer function.
I have used it manually, the respective line number change with every version.

I don't understand why it's so wrong to allow users to not send their PGP attached to every email.
Reasons: * Those keys tend to grow over time with more and more acknowledging signatures. * The mails are marked as having an attachment. (Where's that attachment that my collegue sent? will be mixed with all other messages...) * It is a different logical level. (One key - many signatures.) * ...

People will not use crypto is if it is too cumbersome and try to circumvent it. (Compare Kerckhoffs 1883.)

(In reply to Kai Engert (:KaiE:) from comment #38)

[...] But I think we can try to make a hidden configuration option available, which, when deliberately set by the user, doesn't automatically attach the key when signing.

When I search for "pgp" in about:config I am show several "attachPgpKey" switches. Could they be used, as enigmail did?

Yes, we should reuse the old setting, which was account specific.

(In reply to Bat Manuel from comment #35)

This script seems to no longer function.

Updated script at https://paste.debian.net/1169747/

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/2fedbb94de78
If a signed OpenPGP message automatically includes the public key should be configurable. r=PatrickBrunschwig

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Blocks: 1675298

Comment on attachment 9185346 [details]
Bug 1654950 - If a signed OpenPGP message automatically includes the public key should be configurable. r=PatrickBrunschwig

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: many users asked for this enhancement
Testing completed (on c-c, etc.): need test feedback, hence asking for beta approval
Risk to taking this patch (and alternatives if risky): low

Attachment #9185346 - Flags: approval-comm-beta?

Thanks a LOT for implementing this. In comment #38 you wrote: "Although I personally think it shouldn't hurt having this attachment,...". I'm of course very happy that this option now exists, but of course it's also better to implement sth. if you are actually convinced it is useful. So I'll give it another final attempt... I'd like to add one example where this option can be extremely useful: Some of my customers have an automatic mail/virus scanning system installed at their company. It's a large company and neither me nor my customers have any influence on how it's configured etc. When I send these attachments to them (even though I don't use PGP with them nor do they even know how to make use of such a signature), the virus scanner removes the attachment and even sends them a 2nd(!) mail saying sth. along the lines of that they perhaps received a virus/unknown attachment and it has been automatically removed and they should get in touch with the sender. So they call me back... Stop, Rewind & Repeat - for every single mail I send them. You can easily see that I didn't take long until I completely disabled adding any signatures. Not exactly a great outcome. So, emphatic yes to this option :-)

Re the example in comment 46, a company gateway complaining about attached openpgp key files.

What happens if you send a message with an openpgp digital signature, without a public key attachment?
An OpenPGP digital signature is effectively an attachment, too.
Does the gateway accept the digital signature without complaining?

Just tried it - it's accepted. You are right, though, it's weird. I also don't understand why. Although also on my wishlist is: Only encrypt to recipients I have the public key of and only sign mails that are encrypted in the first place. Then we're back to how it worked with Enigmail before. This would spare me lots of time by people asking what all this stuff is about. Until all of this is resolved, I currently don't encrypt and sign at all anymore but send unencrypted mails again - it's too complicated right now to always remember to switch it on/off. But this is, of course, off-topic for this issue here. Thanks for solving this one here :-)

(In reply to Kai Engert (:KaiE:) from comment #47)

Re the example in comment 46, a company gateway complaining about attached openpgp key files.

What happens if you send a message with an openpgp digital signature, without a public key attachment?
An OpenPGP digital signature is effectively an attachment, too.
Does the gateway accept the digital signature without complaining?

On occasion I've also been forced to use the flanking plaintext signature option present in Enigmail.
Mostly relevant for mailing lists or mail servers that tamper with the body of the email rendering the signature invalid.

(In reply to Renato Alves from comment #50)

On occasion I've also been forced to use the flanking plaintext signature option present in Enigmail.
Mostly relevant for mailing lists or mail servers that tamper with the body of the email rendering the signature invalid.

It's 2020 and it's time that PGP inline signature are gone for good and everybody uses PGP/Mime: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ (See the date when it was written)

If your mailing lists managers can't deal with it, it might indicate that it's a pretty old system that should be updated. Every modern mailing list manager does not tamper with messages and rather should add their metadata as additional (unsigned) attachments.

A bit off-topic, but it seems at least the mailman lists I get, as well as topicbox mails are modifying the mails so that signatures get invalid. Which mailing lists managers keep the mails intact?

Comment on attachment 9185346 [details]
Bug 1654950 - If a signed OpenPGP message automatically includes the public key should be configurable. r=PatrickBrunschwig

[Triage Comment]
Approved for beta

Attachment #9185346 - Flags: approval-comm-beta? → approval-comm-beta+
Target Milestone: --- → 84 Branch

To use this pref (in nightly, in the next beta, and hopefully eventually in a stable 78.x release), you have to manually set hidden preferences - at this time we don't have user interface for this flag.

Open preferences and find the config editor.

Filter the list by entering mail.identity.id - now the list will show you all the preferences for all your identities. This tells you which identity identifiers you have in your configuration.

Find the ID of the identity you want to change, for example by looking for the useremail preference. Let's say you find that mail.identity.id5.useremail is "alice@example.com", and that's the account for which you want to change the behavior. Then "id5" is the identifier you need.

Use a right click and use New, Boolean.

As the preference name use the following, where instead of id5, you use the the id that you found above: mail.identity.id5.attachPgpKey
In the next step you'll be asked to select the value. The default is true. If you're here to make this change, then the value you want is "false".

Thanks a lot, Kai! :)

Unfortunately, it doesn't work with the answers.

To send a mail, it works without any problem, the key is not attached.
But to answer the mail, the key is attached by default...

We are almost there! ;)

Status: RESOLVED → REOPENED
Flags: needinfo?(kaie)
Resolution: FIXED → ---

What if Thunderbird pushed back the release of PGP to a later version?
In the meantime, Enigmail could take over.

(In reply to Alex from comment #56)

Unfortunately, it doesn't work with the answers.

To send a mail, it works without any problem, the key is not attached.
But to answer the mail, the key is attached by default...

The new hidden pref seems to be working fine for me: both new compose, and reply to existing, do not attach key by default. That includes replying to a signed message.

Daily 84.0a1 (2020-11-06)
MacOS 10.15.7 (19H2)

(In reply to Alex from comment #56)

Unfortunately, it doesn't work with the answers.

It sounds like you were trying a version that doesn't contain this change yet.

Flags: needinfo?(kaie)

Alex, marking a bug fixed means that it was fixed in the development branch.
We use separate flags for tracking the state of fixes in other versions, such as stable release branches.
It's best to trust the assigned developers to set the flags, based on feedback given.
Closing again.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

(In reply to Kai Engert (:KaiE:) from comment #60)

Alex, marking a bug fixed means that it was fixed in the development branch.
We use separate flags for tracking the state of fixes in other versions, such as stable release branches.
It's best to trust the assigned developers to set the flags, based on feedback given.
Closing again.

Version 78.4.1 is even worse!
It mixes SSL certificates and PGP keys...

It becomes impossible to sign with a PGP key. Thunderbird assigns a certificate to PGP boxes if another box has an SSL certificate!...
And it is impossible to delete the certificate chosen by TH.

https://i.imgur.com/fe3NBwg.png

This bug is not fixed!

I give up, I downgrade to TH 68 and Enigmail.
TH is not ready for PGP...

Goog luck! ;)

Comment on attachment 9185346 [details]
Bug 1654950 - If a signed OpenPGP message automatically includes the public key should be configurable. r=PatrickBrunschwig

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: many people requested this improvement
Testing completed (on c-c, etc.): c-c and beta
Risk to taking this patch (and alternatives if risky): low risk

Attachment #9185346 - Flags: approval-comm-esr78?

Comment on attachment 9185346 [details]
Bug 1654950 - If a signed OpenPGP message automatically includes the public key should be configurable. r=PatrickBrunschwig

[Triage Comment]
Approved for esr78

Attachment #9185346 - Flags: approval-comm-esr78? → approval-comm-esr78+

Cool! A big thank you! I am looking forward to that release.

I'm on 78.4.3 and have mail.identity.id*.attachPgpKey and mail.identity.default.attachPgpKey all set to boolean/false.
So far, I needed to (manually) apply the bugfix after each update. Now I cannot make it work any more.
When will 78.5.0 be released?

When will 78.5.0 be released?

As I understand Thunderbird releases quickly follow corresponding Firefox releases. Firefox 78.5.0 is supposed to be released next Tuesday (2020-11-17), according to https://wiki.mozilla.org/Release_Management/Calendar - so Thunderbird should follow 1-2 days later.

Alternatively, you could use Thunderbird 83.0beta3, which also contains the fix. However TB 83ff are going to remain beta, as the next stable release will be TB 91 (corresponding to Firefox 91 ESR).

As I don't want to risk any breakage due to upgrading to beta and going back, I'd rather wait for 78.5.0 for another couple of days.

Tuesday or Wednesday. Depends how testing goes.

(In reply to Nicolas Dietrich from comment #68)

When will 78.5.0 be released?

As I understand Thunderbird releases quickly follow corresponding Firefox releases. Firefox 78.5.0 is supposed to be released next Tuesday (2020-11-17), according to https://wiki.mozilla.org/Release_Management/Calendar - so Thunderbird should follow 1-2 days later.

I am glad this has landed! Thanks a lot!

Unfortunately,

  • this still requires use of the config editor;
  • the default setting (true) is wrong / bad practice IMHO. I'd suggest to ask the broader PGP community for an opinion on the topic.

Is there already an issue which discusses whether the default should be "attach public key" or "do not attach public key"?

Enigmail user here. Apologies - why there's no option to not include pub key by default?

(In reply to Nicolas Dietrich from comment #70)

I am glad this has landed! Thanks a lot!

Unfortunately,

  • this still requires use of the config editor;
  • the default setting (true) is wrong / bad practice IMHO. I'd suggest to ask the broader PGP community for an opinion on the topic.

Is there already an issue which discusses whether the default should be "attach public key" or "do not attach public key"?

Perhaps bug 1645514
I agree that the default should be: do not attach public key

Hopefully, we won't need a high committee to provide an option button, next to the already existing one for signing. ;-)

By the way:
The attached public key shouldn't contain all signatures. Else mails may get very big if you've been to a few keysigning parties.

For basic functionality the attached key should be "clean".
In the language of GnuPG "clean" means, the key contains only the latest self signature (for each subkey) and doesn't contain any other signatures.

Are there any news on this? It's really annoying to remember to manually exclude it from EVERY email...

We already introduced a preference, see comment 55.

It's a hidden pref, it isn't visible in the user interface, but using the hidden pref allows you to change the default.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: