CVE-2013-1437 Vulnerability in Module::Metadata

[p5pRT]

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

Searchable as RT118955$

[p5pRT]

From @jmdh

Hello Module​::Metadata upstream (CC perl5-security-report as this is
shipped in perl core),

Please see below a security vulnerability reported to the Debian
Project by brian m. carlson. This issue has been assigned the
identifier CVE-2013-1437 by the Debian security team.

I would be grateful if you could confirm that you have received this
mail and could look into providing a fix. Please note that Brian
has requested that the issue be embargoed until 2nd August (and that
he be credited in announcements after that time), but the recipients of
this email should be able to assist with verification/testing of any patch.

The additional public bug report which alludes to the issue is
<http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717213>

Thanks,
Dominic (for the Debian Perl group).

----- Forwarded message from Salvatore Bonaccorso <carnil@​debian.org> -----

Date​: Thu, 18 Jul 2013 07​:48​:25 +0200
From​: Salvatore Bonaccorso <carnil@​debian.org>
To​: "brian m. carlson" <sandals@​crustytoothpaste.net>
Cc​: team@​security.debian.org, John Lightsey <jd@​cpanel.net>, gregoa@​debian.org,
  Dominic Hargreaves <dom@​earth.li>, Niko Tyni <ntyni@​debian.org>
Subject​: Re​: Vulnerability in libmodule-metadata-perl
X-Spam-Status​: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
  DKIM_VALID,FREEMAIL_FROM autolearn=ham version=3.3.2
User-Agent​: Mutt/1.5.21 (2010-09-15)
X-Urchin-Spam-Score-Int​: -18
X-Bogosity​: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2

Hi Brian

[Adding the Perl maintainers Niko and Dominic for perl, and Gregor for
the libmodule-metadata-perl to CC.]

This is only a first 'ping' to confirm your mail arrived.

On Thu, Jul 18, 2013 at 02​:06​:49AM +0000, brian m. carlson wrote​:

The Perl module Module​::Metadata has the following description​:

This module provides a standard way to gather metadata about a .pm
file without executing unsafe code.

This is not true. If you place the attached Foo.pm file in the current
directory and run​:

perl -MModule​::Metadata -E '$info = Module​::Metadata->new_from_file("Foo.pm");'

It throws an exception because the line containing $VERSION does so. In
other words, although the module is not supposed to execute unsafe code,
it allows arbitrary code execution. This may be obvious in light of
#717213; if I had known it had security implications, I wouldn't have
filed the bug.

I feel this warrants a security advisory. I would like to aim for a
release date of August 2nd, which provides about two weeks' time. If
it's possible, I'd like the Debian Security Team to acquire a CVE for
this, and I would like to be credited in the security announcement.

I have CC'd John Lightsey, a member of the security team at cPanel (my
employer), because I believe I have an obligation to inform them. I
expect that they will not disclose or patch the vulnerability
prematurely.

Please let me know if you need more information or if this is suitable.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

package Foo;

our $VERSION = "1.00"; die "Exploited";

1;

Thanks for your report. Can confirm, indeed from a first look it
eval's the line containing the version information in the subroutine
_evaluate_version_line.

So, despite description says so, it still can evaluate code which the
user has not necessarly control of.

Before assigning a CVE, Dominic, Niko​: As Module​::Metadata is also in
Perl core since v5.13.9 could you check/confirm with upstream?

Thanks and regards,
Salvatore

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

[p5pRT]

From @jmdh

Please reply including the new subject line [perl #118955] which
is the perl core reference for this issue.

On Sat, Jul 20, 2013 at 02​:12​:14PM +0100, Dominic Hargreaves wrote​:

Hello Module​::Metadata upstream (CC perl5-security-report as this is
shipped in perl core),

Please see below a security vulnerability reported to the Debian
Project by brian m. carlson. This issue has been assigned the
identifier CVE-2013-1437 by the Debian security team.

I would be grateful if you could confirm that you have received this
mail and could look into providing a fix. Please note that Brian
has requested that the issue be embargoed until 2nd August (and that
he be credited in announcements after that time), but the recipients of
this email should be able to assist with verification/testing of any patch.

The additional public bug report which alludes to the issue is
<http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717213>

Thanks,
Dominic (for the Debian Perl group).

----- Forwarded message from Salvatore Bonaccorso <carnil@​debian.org> -----

Date​: Thu, 18 Jul 2013 07​:48​:25 +0200
From​: Salvatore Bonaccorso <carnil@​debian.org>
To​: "brian m. carlson" <sandals@​crustytoothpaste.net>
Cc​: team@​security.debian.org, John Lightsey <jd@​cpanel.net>, gregoa@​debian.org,
Dominic Hargreaves <dom@​earth.li>, Niko Tyni <ntyni@​debian.org>
Subject​: Re​: Vulnerability in libmodule-metadata-perl
X-Spam-Status​: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM autolearn=ham version=3.3.2
User-Agent​: Mutt/1.5.21 (2010-09-15)
X-Urchin-Spam-Score-Int​: -18
X-Bogosity​: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2

Hi Brian

[Adding the Perl maintainers Niko and Dominic for perl, and Gregor for
the libmodule-metadata-perl to CC.]

This is only a first 'ping' to confirm your mail arrived.

On Thu, Jul 18, 2013 at 02​:06​:49AM +0000, brian m. carlson wrote​:

The Perl module Module​::Metadata has the following description​:

This module provides a standard way to gather metadata about a .pm
file without executing unsafe code.

This is not true. If you place the attached Foo.pm file in the current
directory and run​:

perl -MModule​::Metadata -E '$info = Module​::Metadata->new_from_file("Foo.pm");'

It throws an exception because the line containing $VERSION does so. In
other words, although the module is not supposed to execute unsafe code,
it allows arbitrary code execution. This may be obvious in light of
#717213; if I had known it had security implications, I wouldn't have
filed the bug.

I feel this warrants a security advisory. I would like to aim for a
release date of August 2nd, which provides about two weeks' time. If
it's possible, I'd like the Debian Security Team to acquire a CVE for
this, and I would like to be credited in the security announcement.

I have CC'd John Lightsey, a member of the security team at cPanel (my
employer), because I believe I have an obligation to inform them. I
expect that they will not disclose or patch the vulnerability
prematurely.

Please let me know if you need more information or if this is suitable.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

package Foo;

our $VERSION = "1.00"; die "Exploited";

1;

Thanks for your report. Can confirm, indeed from a first look it
eval's the line containing the version information in the subroutine
_evaluate_version_line.

So, despite description says so, it still can evaluate code which the
user has not necessarly control of.

Before assigning a CVE, Dominic, Niko​: As Module​::Metadata is also in
Perl core since v5.13.9 could you check/confirm with upstream?

Thanks and regards,
Salvatore

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

[p5pRT]

From @Leont

On Sat, Jul 20, 2013 at 3​:15 PM, Dominic Hargreaves <dom@​earth.li> wrote​:

Please reply including the new subject line [perl #118955] which
is the perl core reference for this issue.

On Sat, Jul 20, 2013 at 02​:12​:14PM +0100, Dominic Hargreaves wrote​:

Hello Module​::Metadata upstream (CC perl5-security-report as this is
shipped in perl core),

Please see below a security vulnerability reported to the Debian
Project by brian m. carlson. This issue has been assigned the
identifier CVE-2013-1437 by the Debian security team.

I would be grateful if you could confirm that you have received this
mail and could look into providing a fix. Please note that Brian
has requested that the issue be embargoed until 2nd August (and that
he be credited in announcements after that time), but the recipients of
this email should be able to assist with verification/testing of any patch.

The additional public bug report which alludes to the issue is
<http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717213>

Thanks,
Dominic (for the Debian Perl group).

----- Forwarded message from Salvatore Bonaccorso <carnil@​debian.org> -----

Date​: Thu, 18 Jul 2013 07​:48​:25 +0200
From​: Salvatore Bonaccorso <carnil@​debian.org>
To​: "brian m. carlson" <sandals@​crustytoothpaste.net>
Cc​: team@​security.debian.org, John Lightsey <jd@​cpanel.net>, gregoa@​debian.org,
Dominic Hargreaves <dom@​earth.li>, Niko Tyni <ntyni@​debian.org>
Subject​: Re​: Vulnerability in libmodule-metadata-perl
X-Spam-Status​: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM autolearn=ham version=3.3.2
User-Agent​: Mutt/1.5.21 (2010-09-15)
X-Urchin-Spam-Score-Int​: -18
X-Bogosity​: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2

Hi Brian

[Adding the Perl maintainers Niko and Dominic for perl, and Gregor for
the libmodule-metadata-perl to CC.]

This is only a first 'ping' to confirm your mail arrived.

On Thu, Jul 18, 2013 at 02​:06​:49AM +0000, brian m. carlson wrote​:

The Perl module Module​::Metadata has the following description​:

This module provides a standard way to gather metadata about a .pm
file without executing unsafe code.

This is not true. If you place the attached Foo.pm file in the current
directory and run​:

perl -MModule​::Metadata -E '$info = Module​::Metadata->new_from_file("Foo.pm");'

It throws an exception because the line containing $VERSION does so. In
other words, although the module is not supposed to execute unsafe code,
it allows arbitrary code execution. This may be obvious in light of
#717213; if I had known it had security implications, I wouldn't have
filed the bug.

I feel this warrants a security advisory. I would like to aim for a
release date of August 2nd, which provides about two weeks' time. If
it's possible, I'd like the Debian Security Team to acquire a CVE for
this, and I would like to be credited in the security announcement.

I have CC'd John Lightsey, a member of the security team at cPanel (my
employer), because I believe I have an obligation to inform them. I
expect that they will not disclose or patch the vulnerability
prematurely.

Please let me know if you need more information or if this is suitable.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

package Foo;

our $VERSION = "1.00"; die "Exploited";

1;

Thanks for your report. Can confirm, indeed from a first look it
eval's the line containing the version information in the subroutine
_evaluate_version_line.

So, despite description says so, it still can evaluate code which the
user has not necessarly control of.

Before assigning a CVE, Dominic, Niko​: As Module​::Metadata is also in
Perl core since v5.13.9 could you check/confirm with upstream?

Thanks and regards,
Salvatore

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

I'd say this is a serious documentation bug.

It's working exactly as intended. I wish we could change it (for
obvious reasons), but there are modules out there that are depending
on this behavior. That said, having a safe (but more limited) mode
would be most welcome, and would probably work most of the time
anyway.

Leon

[p5pRT]

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

[p5pRT]

From @Leont

On Sun, Jul 21, 2013 at 10​:03 PM, brian m. carlson
<sandals@​crustytoothpaste.net> wrote​:

Unfortunately, the problem with making this a documentation bug is that
people may now be relying on this behavior. It has been documented as
working this way since 1.0.5 in August 2011. It is not reasonable to
pull out the rug from under users in this way.

I agree that's most unfortunate. That doesn't give us a free pass out
of this mess though; not evaling will break code. Question may be how
much.

As well, I must question the wisdom of eval'ing any sort of data from
outside the running program without a very, very good reason, and very,
very tight checking.

I would question that wisdom too, but that is a mistake made back in
1995 and we're stuck with the consequences. At least PAUSE is doing it
in a Safe compartment, so it "may fail if you're doing file IO or
other potentially dangerous things within that line".

I suspect the way out would be to emulate that​: evaluate it in a Safe
compartment. It's not a perfect solution but probably good enough.
Some users may already be doing that.

Since this is a module included in core Perl, I
expect it to be of excellent quality and secure by default. For these
reasons, I cannot accept that a documentation fix is a suitable
resolution to this issue.

This module wasn't initially written for use-cases where security
matters; it was written as a accessory module of Module​::Build but
later on got used for other purposes too.

I discovered this bug because simply doing a "use RDF​::Trine" in taint
mode is no longer possible. Since at the very least you're going to
have to make this taint-clean (maybe not as part of this security issue,
but eventually), you might as well fix the security issue.

Any fix should not break distributions using Module​::Build, or any
other part of the toolchain.

Leon

[p5pRT]

From sandals@crustytoothpaste.net

On Sun, Jul 21, 2013 at 05​:11​:43PM +0200, Leon Timmermans wrote​:

I'd say this is a serious documentation bug.

It's working exactly as intended. I wish we could change it (for
obvious reasons), but there are modules out there that are depending
on this behavior. That said, having a safe (but more limited) mode
would be most welcome, and would probably work most of the time
anyway.

Unfortunately, the problem with making this a documentation bug is that
people may now be relying on this behavior. It has been documented as
working this way since 1.0.5 in August 2011. It is not reasonable to
pull out the rug from under users in this way.

As well, I must question the wisdom of eval'ing any sort of data from
outside the running program without a very, very good reason, and very,
very tight checking. Since this is a module included in core Perl, I
expect it to be of excellent quality and secure by default. For these
reasons, I cannot accept that a documentation fix is a suitable
resolution to this issue.

I discovered this bug because simply doing a "use RDF​::Trine" in taint
mode is no longer possible. Since at the very least you're going to
have to make this taint-clean (maybe not as part of this security issue,
but eventually), you might as well fix the security issue.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @rjbs

* Leon Timmermans <fawaka@​gmail.com> [2013-07-21T11​:11​:43]

I'd say this is a serious documentation bug.

It's working exactly as intended. I wish we could change it (for
obvious reasons), but there are modules out there that are depending
on this behavior. That said, having a safe (but more limited) mode
would be most welcome, and would probably work most of the time
anyway.

This is my feeling as well. A safe (but less useful) version should be
provided, and the documentation should be updated to make clear which is static
and which is unsafe. Using a Safe compartment may or may not be worth baking
into the module itself.

I can inform vendors of this problem with an embargo, followed by a fixed
release simultaneous to CPAN and blead.

If anybody has a better idea, the time to speak up is now.

--
rjbs

[p5pRT]

From carnil@debian.org

Hi Ricardo,

On Wed, Jul 24, 2013 at 12​:46​:47AM -0400, Ricardo Signes wrote​:

* Leon Timmermans <fawaka@​gmail.com> [2013-07-21T11​:11​:43]

I'd say this is a serious documentation bug.

It's working exactly as intended. I wish we could change it (for
obvious reasons), but there are modules out there that are depending
on this behavior. That said, having a safe (but more limited) mode
would be most welcome, and would probably work most of the time
anyway.

This is my feeling as well. A safe (but less useful) version should be
provided, and the documentation should be updated to make clear which is static
and which is unsafe. Using a Safe compartment may or may not be worth baking
into the module itself.

I can inform vendors of this problem with an embargo, followed by a fixed
release simultaneous to CPAN and blead.

Yes this should be fine, thank you for the followups.

Regards,
Salvatore

[p5pRT]

From sandals@crustytoothpaste.net

On Wed, Jul 24, 2013 at 12​:46​:47AM -0400, Ricardo Signes wrote​:

This is my feeling as well. A safe (but less useful) version should
be provided, and the documentation should be updated to make clear
which is static and which is unsafe. Using a Safe compartment may or
may not be worth baking into the module itself.

As I said, since people are probably relying on the documented behavior,
it's not acceptable to leave the default version insecure. You are
essentially favoring edge-case functionality over security. If you are
not interested in fixing this properly, that will influence my decision
on whether to report Perl-related security issues privately or not in
the future. I am a strong fan of responsible disclosure, but with that
comes the responsibility of upstream to address the issue adequately.

I can inform vendors of this problem with an embargo, followed by a fixed
release simultaneous to CPAN and blead.

If anybody has a better idea, the time to speak up is now.

The module can be patched to check for valid $VERSION values and accept
only those. It should be fairly easy for someone with lots of extra
disk space to check the $VERSION lines of CPAN modules and find out what
forms are in use.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @tonycoz

On Wed, Jul 24, 2013 at 10​:57​:44PM +0000, brian m. carlson wrote​:

The module can be patched to check for valid $VERSION values and accept
only those. It should be fairly easy for someone with lots of extra
disk space to check the $VERSION lines of CPAN modules and find out what
forms are in use.

Here's a few different CPAN $VERSION initializations​:

our $VERSION = sprintf "%d.%03d", q$Revision​: 3.2 $ =~ /(\d+)\.(\d+)/g;

our $VERSION = do { my @​r = (q$Revision​: 175 $ =~ /\d+/g); sprintf "%d."."%03d" x $#r, @​r };

$VERSION=(0+sprintf('%u.%03u',(q$Id​: XAO.pm,v 2.1 2005/01/14 01​:39​:56 am Exp $ =~ /\s(\d+)\.(\d+)\s/))) || die "Bad VERSION";

our $VERSION = do { my ($v) = (q$Revision​: 687 $ =~ /\d+/mxsg); $v; };

and many more.

See​:

http​://grep.cpan.me/?q=\%24VERSION\s*%3D\s*[^'"\d.\s] file%3A\.pm%24

for more.

Most appear to use simple initialization with a string or number
though.

Tony

[p5pRT]

From sandals@crustytoothpaste.net

On Thu, Jul 25, 2013 at 10​:02​:52AM +1000, Tony Cook wrote​:

On Wed, Jul 24, 2013 at 10​:57​:44PM +0000, brian m. carlson wrote​:

The module can be patched to check for valid $VERSION values and accept
only those. It should be fairly easy for someone with lots of extra
disk space to check the $VERSION lines of CPAN modules and find out what
forms are in use.

Here's a few different CPAN $VERSION initializations​:

our $VERSION = sprintf "%d.%03d", q$Revision​: 3.2 $ =~ /(\d+)\.(\d+)/g;

our $VERSION = do { my @​r = (q$Revision​: 175 $ =~ /\d+/g); sprintf "%d."."%03d" x $#r, @​r };

$VERSION=(0+sprintf('%u.%03u',(q$Id​: XAO.pm,v 2.1 2005/01/14 01​:39​:56 am Exp $ =~ /\s(\d+)\.(\d+)\s/))) || die "Bad VERSION";

our $VERSION = do { my ($v) = (q$Revision​: 687 $ =~ /\d+/mxsg); $v; };

I think these are a good argument against CVS and SVN, if nothing else,
and I question the wisdom of supporting them, but oh, well.

Anyway, if the concern is that Module​::Build will break, why not fix the
existing Module​::Metadata methods, add unsafe ones with big warnings (or
a flag argument to the constructor), and let Module​::Build use the
unsafe ones. Then you don't break the existing interface, and since
you're going to compile and install those modules with Module​::Build
anyway, there's no expectation of security.

For example​:

  # Secure by default.
  my $info = Module​::Metadata->new_from_file($file);
 
  # Exploit me, please!
  my $info = Module​::Metadata->new_from_file($file, insecure => 1);

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @Leont

On Thu, Jul 25, 2013 at 12​:57 AM, brian m. carlson
<sandals@​crustytoothpaste.net> wrote​:

As I said, since people are probably relying on the documented behavior,
it's not acceptable to leave the default version insecure. You are
essentially favoring edge-case functionality over security.

You're missing a point here. Getting a version is inherently a
Turing-complete and thus unsafe operation. What you want is safely
getting to a possibly wrong result. **Safe and correct are mutually
exclusive here**, for various subtle reasons. There are lots of
use-cases where security is not a concern but correctness is.
Module​::Metadata was written for those use cases, and we still need it
to work in that use-case.

That may suck for people who depended on Module​::Metadata being safe
(if anyone really does), but that's still an entirely different order
of magnitude of breakage than what you're proposing. The obvious
solution here is to provide solutions for both use-cases. Suggestions
are most welcome.

Leon

[p5pRT]

From @Leont

On Thu, Jul 25, 2013 at 2​:21 AM, brian m. carlson
<sandals@​crustytoothpaste.net> wrote​:

Anyway, if the concern is that Module​::Build will break, why not fix the
existing Module​::Metadata methods, add unsafe ones with big warnings (or
a flag argument to the constructor), and let Module​::Build use the
unsafe ones. Then you don't break the existing interface, and since
you're going to compile and install those modules with Module​::Build
anyway, there's no expectation of security.

For example​:

# Secure by default.
my $info = Module​::Metadata->new_from_file($file);

# Exploit me, please!
my $info = Module​::Metadata->new_from_file($file, insecure => 1);

Except that it will now break if someone upgrades Module​::Metadata
without upgrading Module​::Build. As sucky as it may be, the default
would have to be the old behavior.

Leon

[p5pRT]

From sandals@crustytoothpaste.net

On Thu, Jul 25, 2013 at 02​:31​:25AM +0200, Leon Timmermans wrote​:

For example​:

# Secure by default.
my $info = Module​::Metadata->new_from_file($file);

# Exploit me, please!
my $info = Module​::Metadata->new_from_file($file, insecure => 1);

Except that it will now break if someone upgrades Module​::Metadata
without upgrading Module​::Build. As sucky as it may be, the default
would have to be the old behavior.

You can use a well-placed conditional die if Module​::Metadata is called
from an old version of Module​::Build, or you can simply let it die if
the version read can't be done securely. There are already modules on
which the current code won't work, and this just increases the number
somewhat.

I understand that there aren't any great alternatives. But you
documented it as being secure, and now you have to honor that, with all
the pain that entails. The term in law is "promissory estoppel." If
you're not going to make the interface secure by default as the
documentation says, I can't consider the issue resolved.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @Leont

On Thu, Jul 25, 2013 at 2​:59 AM, brian m. carlson
<sandals@​crustytoothpaste.net> wrote​:

I understand that there aren't any great alternatives. But you
documented it as being secure, and now you have to honor that, with all
the pain that entails. The term in law is "promissory estoppel." If
you're not going to make the interface secure by default as the
documentation says, I can't consider the issue resolved.

Could you please get off your high horse? If you want to convince us
that your solution is "pullling out the rug from under users" less
then mine, can you please come with an actual argument to support your
case? Throwing around legal terms isn't quite that.

Leon

[p5pRT]

From sandals@crustytoothpaste.net

On Thu, Jul 25, 2013 at 03​:46​:40AM +0200, Leon Timmermans wrote​:

Could you please get off your high horse? If you want to convince us
that your solution is "pullling out the rug from under users" less
then mine, can you please come with an actual argument to support your
case? Throwing around legal terms isn't quite that.

I've made an argument. You seem unconvinced. So let's cut to the
chase​: either you're going to fix the bug, or you're not. If you're
not, then there's no point arguing about it, and I might as well just
let the Debian maintainer know what the real issue is so I can get
RDF​::Trine to work again in taint mode.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @rjbs

* Ricardo Signes <perl.security@​rjbs.manxome.org> [2013-07-24T00​:46​:47]

A safe (but less useful) version should be provided, and the documentation
should be updated to make clear which is static and which is unsafe. Using a
Safe compartment may or may not be worth baking into the module itself.

I can inform vendors of this problem with an embargo, followed by a fixed
release simultaneous to CPAN and blead.

This is how we will be proceeding. I am at a conference this week, and am
unlikely to make much progress on this. I hope to get movement on this Monday,
or perhaps sooner.

--
rjbs

[p5pRT]

From sandals@crustytoothpaste.net

I should apologize for my behavior last night. I went beyond zealous
advocacy for my position and was excessively difficult and rude. In the
future, I will avoid responding to email when irritated or annoyed.

Again, my apologies.

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

--
brian m. carlson / brian with sandals​: Houston, Texas, US
+1 832 623 2791 | http​://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP​: RSA v4 4096b​: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[p5pRT]

From @rjbs

* Ricardo Signes <perl.security@​rjbs.manxome.org> [2013-07-24T00​:46​:47]

This is my feeling as well. A safe (but less useful) version should be
provided, and the documentation should be updated to make clear which is static
and which is unsafe. Using a Safe compartment may or may not be worth baking
into the module itself.

I can inform vendors of this problem with an embargo, followed by a fixed
release simultaneous to CPAN and blead.

I spent a bit of time looking into this tonight. The way the library is
factored makes it non-trivial to add a non-evaluating version. I'm going to
talk to Matt S Trout, the library's primary maintainer, and Tomas Doran
(already cc'd on this ticket) the last uploader of the library, about getting
a patch prepared "off the grid" to follow up with the above plan.

--
rjbs

[p5pRT]

From @rjbs

* Ricardo Signes <perl.security@​rjbs.manxome.org> [2013-07-29T22​:53​:12]

I spent a bit of time looking into this tonight. The way the library is
factored makes it non-trivial to add a non-evaluating version. I'm going to
talk to Matt S Trout, the library's primary maintainer, and Tomas Doran
(already cc'd on this ticket) the last uploader of the library, about getting
a patch prepared "off the grid" to follow up with the above plan.

The impression I am getting is that this is only going to get fixed by
correcting the documentation, which seems basically to have just gotten a bad
word chosen when its documentation was reformatted in 6290f67c​:

  https://github.com/dagolden/Module-Metadata/commit/6290f67c

I will inform downstream of the documentation error, with a short notice
period, then get the doc patch published.

--
rjbs

[p5pRT]

From @rjbs

* Ricardo Signes <perl.security@​rjbs.manxome.org> [2013-08-06T22​:24​:26]

https://github.com/dagolden/Module-Metadata/commit/6290f67c

I will inform downstream of the documentation error, with a short notice
period, then get the doc patch published.

I will send a public pull request or patch to Module-Metadata on August 19th,
having promised that delay to downstream.

--
rjbs

[p5pRT]

From @tonycoz

On Sun Aug 11 19​:07​:18 2013, perl.security@​rjbs.manxome.org wrote​:

* Ricardo Signes <perl.security@​rjbs.manxome.org> [2013-08-
06T22​:24​:26]

https://github.com/dagolden/Module-Metadata/commit/6290f67c

I will inform downstream of the documentation error, with a short
notice
period, then get the doc patch published.

I will send a public pull request or patch to Module-Metadata on
August 19th,
having promised that delay to downstream.

This changed was published in Module-Metadata 1.000015 in August last year - should this ticket be made public now?

Tony

[p5pRT]

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

[p5pRT]

From @tonycoz

On Mon Jul 14 22​:37​:18 2014, tonyc wrote​:

This changed was published in Module-Metadata 1.000015 in August last
year - should this ticket be made public now?

Now public.

Tony