Re: Uploaded perl 5.003.07-11 (source i386) to master
On Thu, 7 May 1998, Martin Schulze wrote: > On Thu, May 07, 1998 at 07:41:02AM +0200, Alexander Koch wrote: > > On Thu, 7 May 1998 01:48:56 -, Christian Hudon wrote: > > > Source: perl > > > Binary: perl-suid perl-debug perl > > > Version: 5.003.07-11 > > > Distribution: stable > > > Urgency: high > > Changes: fixes security problem. > > This is not a real upload, isn't it? Since 5.003.whatever is a bit ... > > out-dated for years? > > It is a real upload. It's a security fix for our stable release. > Uploads into stable may only fix security problems and should not > introduce new upstream releases. But 5.003_07 is still quite vulnerable to a once widely-circulated buffer overflow attack. Only upgrading to 5.004_04 will fix that problem.[*] Now whether users *want* to upgrade their stable systems to 5.004_04 is another question, and it probably has different answers depending on whether or not the users run suid scripts vulnerable to the buffer overflow or whether they want the absolute stability of sticking with 5.003_07. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 [*] Well, I guess I could probably plug that one hole without touching much else, if there's really enough need. The resulting perl would still have a few quite obscure buffer overflow possibilities, but nothing for which I'm aware of any widely circulated automated attacks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#1732: Bad arithmetic in new perl packages
On Sun, 22 Oct 1995, J.H.M.Dassen wrote: > Fernando wrote to debian-bugs: (problem with 5.001m, but not 5.001e) > > Perl seems to be confused making some arithmetic operations (additions). > > Sometimes the result of $a+=$b, when $a is 0 and $b is 2 happens to be > > 2.04192 or something similar. Without seeing a short example script, it's dangerous to guess, but I'll do so anyway. There is a very subtle bug that can arise in some rare situations where perl has to convert back and forth between string and floating point representations, but that's almost certainly not the problem here. I also can't think of anything in 5.001m (as opposed to 5.001e) that might have affected this. I'd guess one of two things is going on: 1. This is the usual sort of problem that arises when folks forget that floating point arithmetic isn't exact. Perl5 is pretty forgiving, and tries hard to print what you want, but doesn't always succeed. 2. The tests are running on a buggy pentium :-). > Fernando, I unfortunately have no idea what is causing this. Please > provide a short script which shows this behaviour (reliably if possible). Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: How can Debian accomodate new installation ?
On Thu, 8 Oct 1998, Stephen Zander wrote: > It's not clear to me why debian began installing modules in perl_arch > by default. Perhaps Darren knows. Debian (sensibly, in my opinion) puts $sitelib and $sitearch in /usr/local and leaves them for the individual end user to use to install local extensions. The problem arises, then, what to do with modules such as Tk, which Debian supplies in precompiled form. Darren's solution of putting all Debian-supplied extensions (be they part of the perl core, such as POSIX.so or optional extensions, such as Tk.so) in the Debian-controlled /usr/lib/perl5 hierarchy makes good sense to me. The problem then arises what to do when perl undergoes a minor maintenance revision (e.g. 5.004_02 -> 5.004_03). Since these minor maintenance revisions are supposed to maintain binary compatibility, there is no need to recompile all the add-on extensions right away. However, the default perl installation directory would have changed from 5.00402 to 5.00403, and suddenly the modules would have apparently disappeared. Darren neatly solved _that_ problem by omitting the subversion number on maintenance releases so that all of 5.004_0x modules go into the /usr/lib/perl5/i386-linux/5.004/ directory. Upgrades between compatible perl maintenance subversions then don't break other modules. One of the primary purposes of perl's installation directory structure (and recent reorganization) was to allow users to have more than one version of perl installed at a time. Debian users generally don't do that -- perl5.005 will replace 5.004 -- so the installation hierarchy probably doesn't help all that much. Once 5.004 is replaced, all the compiled modules that were built under it will become immediately non-working, and they will need to be replaced too. (I suppose one could draw upon the a.out->ELF or libc5-libc6 experience to try to make a smooth transition, but I'm not sure it'd be worth it.) Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl 5.005.02
[ perl5.005_02's default library is now /usr/lib/perl5/perl5.005,
and might change with 5.006, etc.]
> Any idea how to handle this properly ? Maybe we need a sort of perl
> policy : package will have to install file under /usr/lib/perl5/debian
> which would be a symlink to the current perl version ? But
> this does not solve all problems... Better idea ?
Yes. Perl itself knows where it is installed. Install .pm things into
$Config{'privlib'}. From the shell command line, you can get this
same information with /usr/bin/perl -V:privlib.
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Perl 5.005.02
On Fri, 9 Oct 1998, Andy Dougherty wrote: > [ perl5.005_02's default library is now /usr/lib/perl5/perl5.005, > and might change with 5.006, etc.] > > > Any idea how to handle this properly ? Maybe we need a sort of perl > > policy : package will have to install file under /usr/lib/perl5/debian > > which would be a symlink to the current perl version ? But > > this does not solve all problems... Better idea ? After some thought, I think I'd recommend that perl5.005_xx retain the same directory structure that perl5.00[34]_xx did. (with 5.005 in place of 5.00[34], of course). Perl's default directory structure is designed to accomodate the simultaneous installation of more than one perl version. Since Debian doesn't do that, there's no reason to put versions in separate version-specific directories. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl 5.005.02
On Sun, Oct 11, 1998 at 11:28:06AM -0400, Roderick Schertler wrote:
> > Andy Dougherty, in an immanent manifestation of deity, wrote:
> >>
> >> After some thought, I think I'd recommend that perl5.005_xx retain the
> >> same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
> >> 5.00[34], of course).
> I don't think Andy is taking into account your plan of allowing both
> threaded and non-threaded Perls present on the system at the same time.
That shouldn't matter, since the threaded version ought to have it's
own $Config{'archname'} and put all the thread-specific files in something
vaguely like /usr/lib/perl5/i386-linux-thread (Configure handles this
automatically). The threaded and non-threaded versions can share the rest
of the files. (Well, there can be only one /usr/bin/perl, of course:-).
I don't know how to tell dpkg that such files are shared, however.
If, however, Debian does move towards supporting simultaneous installation
of multiple perl versions, then I think the new 5.005 default directory
structure still won't be rich enough. In that case, Debian probably ought
to introduce a new set of directories--perhaps call them $vendor_arch and
$vendor_lib--to hold Debian-supplied extensions and modules. These would
work just like the /usr/local/lib/site* variables (in how they track
changes in perl versions) but they would be in the /usr/lib/ hierarchy for
Debian to use.
> It seems to me that the only real problem we've got with the current
> layout is that the *.pm files for extensions which have XS portions are
> placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.
I thought MakeMaker was supposed to do that automatically already. I'd
consider that a MakeMaker bug.
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
