Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2018-12015: Archive::Tar: directory traversal #16580

Closed
p5pRT opened this issue Jun 5, 2018 · 23 comments
Closed

CVE-2018-12015: Archive::Tar: directory traversal #16580

p5pRT opened this issue Jun 5, 2018 · 23 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jun 5, 2018

Migrated from rt.perl.org#133250 (status was 'resolved')

Searchable as RT133250$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 30, 2017

From @jwilk

By default, the Archive​::Tar module doesn't allow extracting files
outside the current working directory. Unfortunately, you can bypass
this secure extract mode easily by putting a symlink and a regular file
with the same name into the tarball.

Proof of concept, which makes Archive​::Tar create /tmp/moo, regardless
of what cwd is​:

  $ tar -tvvf traversal.tar.gz
  lrwxrwxrwx root/root 0 2017-09-30 15​:36 moo -> /tmp/moo
  -rw-r--r-- root/root 4 2017-09-30 15​:36 moo

  $ pwd
  /home/jwilk

  $ ls /tmp/moo
  ls​: cannot access '/tmp/moo'​: No such file or directory

  $ perl -MArchive​::Tar -e 'Archive​::Tar->extract_archive("traversal.tar.gz")'

  $ ls /tmp/moo
  /tmp/moo

Tested with Perl v5.26.1.

--
Jakub Wilk

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 30, 2017

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 30, 2017

From @tonycoz

On Sat, Sep 30, 2017 at 12​:23​:38PM -0700, Jakub Wilk wrote​:

# New Ticket Created by Jakub Wilk
# Please include the string​: [perl #132189]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132189 >

By default, the Archive​::Tar module doesn't allow extracting files
outside the current working directory. Unfortunately, you can bypass
this secure extract mode easily by putting a symlink and a regular file
with the same name into the tarball.

Proof of concept, which makes Archive​::Tar create /tmp/moo, regardless
of what cwd is​:

$ tar -tvvf traversal.tar.gz
lrwxrwxrwx root/root 0 2017-09-30 15​:36 moo -> /tmp/moo
-rw-r--r-- root/root 4 2017-09-30 15​:36 moo

$ pwd
/home/jwilk

$ ls /tmp/moo
ls​: cannot access '/tmp/moo'​: No such file or directory

$ perl -MArchive​::Tar -e 'Archive​::Tar->extract_archive("traversal.tar.gz")'

$ ls /tmp/moo
/tmp/moo

Tested with Perl v5.26.1.

This needs to be reported to the Archive​::Tar maintainer, not here.

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 30, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 5, 2018

From @jmdh

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any file
writable by the extracting user. The same problem does not exist in
(eg) GNU tar, and I assume that must explicitly protect against this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl 5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can help at
all.

Note​: I'm reporting this in private, but it was already publically
disclosed at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834>.

Dominic.

----- Forwarded message from Jakub Wilk <jwilk@​jwilk.net> -----

Date​: Tue, 5 Jun 2018 19​:03​:33 +0200
From​: Jakub Wilk <jwilk@​jwilk.net>
To​: submit@​bugs.debian.org
Subject​: Bug#900834​: perl​: Archive​::Tar​: directory traversal

Source​: perl
Version​: 5.26.2-5
Tags​: security

By default, the Archive​::Tar module doesn't allow extracting files outside the
current working directory. However, you can bypass this secure extraction mode
easily by putting a symlink and a regular file with the same name into the
tarball.

I've attached proof of concept tarball, which makes Archive​::Tar create
/tmp/moo, regardless of what the current working directory is​:

  $ tar -tvvf traversal.tar.gz
  lrwxrwxrwx root/root 0 2018-06-05 18​:55 moo -> /tmp/moo
  -rw-r--r-- root/root 4 2018-06-05 18​:55 moo

  $ pwd
  /home/jwilk

  $ ls /tmp/moo
  ls​: cannot access '/tmp/moo'​: No such file or directory

  $ perl -MArchive​::Tar -e 'Archive​::Tar->extract_archive("traversal.tar.gz")'

  $ ls /tmp/moo
  /tmp/moo

--
Jakub Wilk

_______________________________________________
Perl-maintainers mailing list
Perl-maintainers@​alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/perl-maintainers

----- End forwarded message -----

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 6, 2018

From carnil@debian.org

Hi Dominic,

On Tue, Jun 05, 2018 at 11​:00​:41PM +0100, Dominic Hargreaves wrote​:

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any file
writable by the extracting user. The same problem does not exist in
(eg) GNU tar, and I assume that must explicitly protect against this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl 5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can help at
all.

Note​: I'm reporting this in private, but it was already publically
disclosed at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834>.

I just have requested a CVE from MITRE, will ping here again when I
have the CVE assignment.

Regards,
Salvatore

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 7, 2018

From carnil@debian.org

Hi!

On Tue, Jun 05, 2018 at 11​:00​:41PM +0100, Dominic Hargreaves wrote​:

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any file
writable by the extracting user. The same problem does not exist in
(eg) GNU tar, and I assume that must explicitly protect against this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl 5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can help at
all.

Note​: I'm reporting this in private, but it was already publically
disclosed at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834>.

MITRE has assigned CVE-2018-12015 for this issue.

Will look if I find time to write to oss-security as well on the CVE
assignment, but otherwise other distros will anyway notice once they
update their CVE list.

Is there a (public) upstream bugreport on it?

Regards,
Salvatore

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 7, 2018

From @jmdh

On Thu, Jun 07, 2018 at 03​:13​:34PM +0200, Salvatore Bonaccorso wrote​:

Hi!

On Tue, Jun 05, 2018 at 11​:00​:41PM +0100, Dominic Hargreaves wrote​:

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any file
writable by the extracting user. The same problem does not exist in
(eg) GNU tar, and I assume that must explicitly protect against this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl 5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can help at
all.

Note​: I'm reporting this in private, but it was already publically
disclosed at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834>.

MITRE has assigned CVE-2018-12015 for this issue.

Will look if I find time to write to oss-security as well on the CVE
assignment, but otherwise other distros will anyway notice once they
update their CVE list.

Is there a (public) upstream bugreport on it?

Thanks. I've just created one here​:

https://rt.cpan.org/Ticket/Display.html?id=125523

I was holding off on that but since it's already public in the BTS,
probably not much advantage.

There was some indication that someone from p5p-security was looking into
it but I'm not sure. It would probably be better if someone who already
understands the code does so?

Cheers,
Dominic.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 8, 2018

From @jmdh

On Thu, Jun 07, 2018 at 10​:33​:05PM +0100, Dominic Hargreaves wrote​:

On Thu, Jun 07, 2018 at 03​:13​:34PM +0200, Salvatore Bonaccorso wrote​:

Hi!

On Tue, Jun 05, 2018 at 11​:00​:41PM +0100, Dominic Hargreaves wrote​:

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any file
writable by the extracting user. The same problem does not exist in
(eg) GNU tar, and I assume that must explicitly protect against this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl 5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can help at
all.

Note​: I'm reporting this in private, but it was already publically
disclosed at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834>.

MITRE has assigned CVE-2018-12015 for this issue.

Will look if I find time to write to oss-security as well on the CVE
assignment, but otherwise other distros will anyway notice once they
update their CVE list.

Is there a (public) upstream bugreport on it?

Thanks. I've just created one here​:

https://rt.cpan.org/Ticket/Display.html?id=125523

I was holding off on that but since it's already public in the BTS,
probably not much advantage.

There was some indication that someone from p5p-security was looking into
it but I'm not sure. It would probably be better if someone who already
understands the code does so?

There's now a proposed patch there from Petr at Redhat. Any chance someone
can have a look to review it?

Thanks!
Dominic.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2018

From @tonycoz

On Fri, 08 Jun 2018 06​:52​:40 -0700, dom wrote​:

On Thu, Jun 07, 2018 at 10​:33​:05PM +0100, Dominic Hargreaves wrote​:

On Thu, Jun 07, 2018 at 03​:13​:34PM +0200, Salvatore Bonaccorso wrote​:

Hi!

On Tue, Jun 05, 2018 at 11​:00​:41PM +0100, Dominic Hargreaves wrote​:

Hi all,

Please see this report of a directory traversal vulnerability in
Archive​::Tar, which could be trivially exploited to overwrite any
file
writable by the extracting user. The same problem does not exist
in
(eg) GNU tar, and I assume that must explicitly protect against
this
case.

Verified with Archive​::Tar 2.04_01 (perl 5.24.1), 2.24 (perl
5.26.2) and
2.26 (perl 5.28.0-RC1).

I expect the Debian security team (in To​:) can assist by
supplying a
CVE if needed. Let me know if we (Debian perl maintainers) can
help at
all.

Note​: I'm reporting this in private, but it was already
publically
disclosed at <https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=900834>.

MITRE has assigned CVE-2018-12015 for this issue.

Will look if I find time to write to oss-security as well on the
CVE
assignment, but otherwise other distros will anyway notice once
they
update their CVE list.

Is there a (public) upstream bugreport on it?

Thanks. I've just created one here​:

https://rt.cpan.org/Ticket/Display.html?id=125523

I was holding off on that but since it's already public in the BTS,
probably not much advantage.

There was some indication that someone from p5p-security was looking
into
it but I'm not sure. It would probably be better if someone who
already
understands the code does so?

There's now a proposed patch there from Petr at Redhat. Any chance
someone
can have a look to review it?

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

Please ensure [perl #133250] is in the subject, I just merged four other tickets into this one.

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2018

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 9, 2018

From @tonycoz

On Fri, 08 Jun 2018 17​:30​:17 -0700, tonyc wrote​:

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

How do we want to handle this[1] for maint releases?

Do we​:

a) ignore it, let the users update from CPAN even with the next maint-5.26, or

b) include the fix and only the fix.

I think we've typically done a), but the dot-in-inc maint changes included changes to cpan/

Tony

[1] and other similar issues in the future

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 9, 2018

From @iabyn

On Wed, Aug 08, 2018 at 06​:23​:16PM -0700, Tony Cook via RT wrote​:

On Fri, 08 Jun 2018 17​:30​:17 -0700, tonyc wrote​:

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

How do we want to handle this[1] for maint releases?

Do we​:

a) ignore it, let the users update from CPAN even with the next maint-5.26, or

b) include the fix and only the fix.

I think we've typically done a), but the dot-in-inc maint changes included changes to cpan/

I think its a subjective per-issue decision. In this case I think the
issue is serious enough that we should do (b).

--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
  -- Things That Never Happen in "Star Trek" #10

1 similar comment
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 9, 2018

From @iabyn

On Wed, Aug 08, 2018 at 06​:23​:16PM -0700, Tony Cook via RT wrote​:

On Fri, 08 Jun 2018 17​:30​:17 -0700, tonyc wrote​:

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

How do we want to handle this[1] for maint releases?

Do we​:

a) ignore it, let the users update from CPAN even with the next maint-5.26, or

b) include the fix and only the fix.

I think we've typically done a), but the dot-in-inc maint changes included changes to cpan/

I think its a subjective per-issue decision. In this case I think the
issue is serious enough that we should do (b).

--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
  -- Things That Never Happen in "Star Trek" #10

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 11, 2018

From @xsawyerx

I agree. We should go with (b) here.

On Thu, Aug 9, 2018 at 10​:07 AM Dave Mitchell <davem@​iabyn.com> wrote​:

On Wed, Aug 08, 2018 at 06​:23​:16PM -0700, Tony Cook via RT wrote​:

On Fri, 08 Jun 2018 17​:30​:17 -0700, tonyc wrote​:

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

How do we want to handle this[1] for maint releases?

Do we​:

a) ignore it, let the users update from CPAN even with the next
maint-5.26, or

b) include the fix and only the fix.

I think we've typically done a), but the dot-in-inc maint changes
included changes to cpan/

I think its a subjective per-issue decision. In this case I think the
issue is serious enough that we should do (b).

--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in "Star Trek" #10

1 similar comment
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 11, 2018

From @xsawyerx

I agree. We should go with (b) here.

On Thu, Aug 9, 2018 at 10​:07 AM Dave Mitchell <davem@​iabyn.com> wrote​:

On Wed, Aug 08, 2018 at 06​:23​:16PM -0700, Tony Cook via RT wrote​:

On Fri, 08 Jun 2018 17​:30​:17 -0700, tonyc wrote​:

Chris has released a 2.28 with the fix​:

https://metacpan.org/release/BINGOS/Archive-Tar-2.28

How do we want to handle this[1] for maint releases?

Do we​:

a) ignore it, let the users update from CPAN even with the next
maint-5.26, or

b) include the fix and only the fix.

I think we've typically done a), but the dot-in-inc maint changes
included changes to cpan/

I think its a subjective per-issue decision. In this case I think the
issue is serious enough that we should do (b).

--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in "Star Trek" #10

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 20, 2018

From @tonycoz

In blead/5.28 this was fixed in 91f84d6 (v5.28.0-RC2-3-g91f84d6f2b).

The attached patch includes the backport of *only* the CVE fix to maint-5.26.

jib/archive-tar-new@ae65651

An alternative might be to simply import Archive-Tar 2.28 (or 2.32) but we've typically stuck to minimal fixes for included CPAN modules.

Since this issue is public, given two other votes I'll apply it immediately to maint-5.26 and make this ticket public.

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 20, 2018

From @tonycoz

0001-perl-133250-backport-CVE-2018-12015-fix.patch
From fe83582298e0746ff3b663110d5a6a4b299c96b8 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 20 Sep 2018 11:53:19 +1000
Subject: (perl #133250) backport CVE-2018-12015 fix

---
 Porting/Maintainers.pl              |  1 +
 cpan/Archive-Tar/lib/Archive/Tar.pm | 17 ++++++++++++++++-
 t/porting/customized.dat            |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/Porting/Maintainers.pl b/Porting/Maintainers.pl
index e9032a91f3..5f3b3141d1 100755
--- a/Porting/Maintainers.pl
+++ b/Porting/Maintainers.pl
@@ -126,6 +126,7 @@ use File::Glob qw(:case);
         'EXCLUDED'     => [
             qw(t/07_ptardiff.t),
         ],
+        'CUSTOMIZED' => [ qw(lib/Archive/Tar.pm) ], # CVE-2018-12015
     },
 
     'Attribute::Handlers' => {
diff --git a/cpan/Archive-Tar/lib/Archive/Tar.pm b/cpan/Archive-Tar/lib/Archive/Tar.pm
index d63e586317..00db612193 100644
--- a/cpan/Archive-Tar/lib/Archive/Tar.pm
+++ b/cpan/Archive-Tar/lib/Archive/Tar.pm
@@ -31,7 +31,7 @@ use vars qw[$DEBUG $error $VERSION $WARN $FOLLOW_SYMLINK $CHOWN $CHMOD
 $DEBUG                  = 0;
 $WARN                   = 1;
 $FOLLOW_SYMLINK         = 0;
-$VERSION                = "2.24";
+$VERSION                = "2.24_01";
 $CHOWN                  = 1;
 $CHMOD                  = 1;
 $SAME_PERMISSIONS       = $> == 0 ? 1 : 0;
@@ -845,6 +845,21 @@ sub _extract_file {
         return;
     }
 
+    ### If a file system already contains a block device with the same name as
+    ### the being extracted regular file, we would write the file's content
+    ### to the block device. So remove the existing file (block device) now.
+    ### If an archive contains multiple same-named entries, the last one
+    ### should replace the previous ones. So remove the old file now.
+    ### If the old entry is a symlink to a file outside of the CWD, the new
+    ### entry would create a file there. This is CVE-2018-12015
+    ### <https://rt.cpan.org/Ticket/Display.html?id=125523>.
+    if (-l $full || -e _) {
+	if (!unlink $full) {
+	    $self->_error( qq[Could not remove old file '$full': $!] );
+	    return;
+	}
+    }
+
     if( length $entry->type && $entry->is_file ) {
         my $fh = IO::File->new;
         $fh->open( '>' . $full ) or (
diff --git a/t/porting/customized.dat b/t/porting/customized.dat
index 5014b3e210..7a5c7fc0b4 100644
--- a/t/porting/customized.dat
+++ b/t/porting/customized.dat
@@ -1,3 +1,4 @@
+Archive::Tar cpan/Archive-Tar/lib/Archive/Tar.pm e93f3f352b4820b3ccdc1f06cb82b2102fe1de3b
 Digest cpan/Digest/Digest.pm 43f7f544cb11842b2f55c73e28930da50774e081
 Encode cpan/Encode/Unicode/Unicode.pm 9749692c67f7d69083034de9184a93f070ab4799
 ExtUtils::Constant cpan/ExtUtils-Constant/t/Constant.t a0369c919e216fb02767a637666bb4577ad79b02
-- 
2.11.0

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 21, 2018

From @arc

tonyc wrote​:

Since this issue is public, given two other votes I'll apply it
immediately to maint-5.26 and make this ticket public.

I can't see an entry in the votes file, but please take this as my vote to merge to maint-5.26.

Thanks, Tony!

--
Aaron Crane

1 similar comment
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 21, 2018

From @arc

tonyc wrote​:

Since this issue is public, given two other votes I'll apply it
immediately to maint-5.26 and make this ticket public.

I can't see an entry in the votes file, but please take this as my vote to merge to maint-5.26.

Thanks, Tony!

--
Aaron Crane

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 21, 2018

From @xsawyerx

Same from me.

On Fri, Sep 21, 2018, 13​:07 Aaron Crane via RT <rt-comment@​perl.org> wrote​:

tonyc wrote​:

Since this issue is public, given two other votes I'll apply it
immediately to maint-5.26 and make this ticket public.

I can't see an entry in the votes file, but please take this as my vote to
merge to maint-5.26.

Thanks, Tony!

--
Aaron Crane

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 24, 2018

From @tonycoz

On Fri, 21 Sep 2018 03​:04​:18 -0700, arc wrote​:

tonyc wrote​:

Since this issue is public, given two other votes I'll apply it
immediately to maint-5.26 and make this ticket public.

I can't see an entry in the votes file, but please take this as my
vote to merge to maint-5.26.

Yeah, there's no corresponding commit in blead, since that included the full
upstream release rather than just the CVE fix.

Applied as d0130b8.

Leaving this open until 5.26.next is released.

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 30, 2018

@xsawyerx - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this Nov 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.