Front page | perl.perl5.porters |
Postings from March 2023
On Wed, Mar 8, 2023 at 3:38â¯PM demerphq <demerphq@gmail.com> wrote:
> > Or better, there's a trusted source of digests and:
> >
> > verified Some::Module => 'v1.2.3';
> >
> > And that would consult the source, figure out what version of
> Some::Module is installed and verify the digest. Of course, it would need
> to do that for all CPAN modules in the project. That might be awfully hard
> if we try to run that against system Perl (especially if vendors are change
> the code). I suspect there are a few devils in the details, but just
> because I have Some::Module installed doesn't mean it's the Some::Module
> from the CPAN.
>
> Hmm. Yes I get you. With the __REQUIRE__ hook I want to add to perl
> this would be trivial to implement in a plug in way. I will look
> further into this one. It gets a bit interesting when you factor in
> source filters, but it is still doable IMO.
>
You know, I just realized this would also help with a long-standing issue.
I've had various clients forbid certain modules. Some modules may not be
used directly in client code, and some must not be even used indirectly
because the author's done something really naughty. You pull in Mega::Module
which loads half of the CPAN and don't notice you have the naughty module,
well, now it will be easier in a central place to drop in:
# syntax is bad, but shows the concept
forbids 'Naughty::Module';
forbids 'Other::Module' => [ '<' => v1.2.3 ];
forbids 'Buggy::Version' => [ '1.4..1.7', '2.3' ];
Probably a lot of this stuff would be marginal value for most, but some of
my larger clients, I have some very specific modules in mind which must
never be loaded.
Best,
Ovid
Thread Previous
|
Thread Next