I was not trivializing it. As you well know Perl is a memory pig and optimized for speed. Part of this optimization is the over allocation of memory for scalars (as the test case shows). In fact Perl over allocates memory for just about all its data types. The reason is simple optimisation. If you don't have to reallocate memory simply to add an extra few bytes to a string, or add an extra element to an array you avoid the memory allocation and copy costs. I can't see a good reason why the gnomes should change this behaviour other than to save memory. I can't see ANY reason why overwriting the value in a scalar with the same number of bytes should EVER change to the situation where Perl is reallocating memory and doing a copy every time. This would be inefficient and is completely unnecessary.

As noted before physically securing the box is to my mind far more important. Just look at the banks for example. How many root kits are there that let you escalate user level privilege to root whereby you can just read the script/config without having to go to the extent of trawling through memory?

package Config;

$key = 'hello';

package Foo;

use Devel::Peek;

my $str = 'the key is:';
Dump($Config::key);
decrypt( $str, $Config::key );

$Config::key = 'x'x19;
Dump($Config::key);
decrypt( $str, $Config::key );

$Config::key = 'x'x20;
Dump($Config::key);
decrypt( $str, $Config::key );

sub decrypt{ warn "Got: @_\n" }

__DATA__
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x15dd0ac "hello"\0
  CUR = 5
  LEN = 6
Got: the key is: hello
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x15dd0ac "xxxxxxxxxxxxxxxxxxx"\0 <--- Same Pointer == overwrit
+e
  CUR = 19
  LEN = 20
Got: the key is: xxxxxxxxxxxxxxxxxxx
SV = PV(0x15d5284) at 0x1a454a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x1a48edc "xxxxxxxxxxxxxxxxxxxx"\0 <--- Reallocation has occurr
+ed
  CUR = 20
  LEN = 21
Got: the key is: xxxxxxxxxxxxxxxxxxxx
[download]

I can't see ANY reason why overwriting the value in a scalar with the same number of bytes should EVER change to the situation where Perl is reallocating memory and doing a copy every time. This would be inefficient and is completely unnecessary.

Just because you and I can't see a reason why it should copy doesn't mean it will not. I can't see a reason why sendmail should overflow buffers, and I don't think the author(s) ever had any intentions it should. But it has happened in the past, and I won't guarantee it will not happen again in the future.

Requirements may change. Ideas may change. Design principles may change. Mistakes may happen. Basing security on "that would be illogical" may work on Vulcan, but not here.

As noted before physically securing the box is to my mind far more important. Just look at the banks for example. How many root kits are there that let you escalate user level privilege to root whereby you can just read the script/config without having to go to the extent of trawling through memory?

Wearing safety belts in a car is more important than having a fire extinguisher in a car. But that doesn't mean that if you decide to buy a fire extinguisher it's unimportant how well it works, and how to mount it in your car.

Furthermore, there are cases where it is important to protect yourself from people with root permission that you can't or won't trust. PGP for instance. Sure, it is possible for someone to replace a kernel to do whatever they want to do, but that is far more difficult than trawling /dev/kmem.

Abigail

Just because you and I can't see a reason why it should copy doesn't mean it will not.

While I pointed out it would seem illogical for this behavior to change, and showed when it currently does, I also presented code that could easily be modified into a persistent test case to ensure that on Vulcan today the weather remains fine ;-) Test cases do work, even on Vulcan, and they do form a resonably reliable way of assessing changes in a particular desired behaviour.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print