Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Re: Blatant security problem in certain CPAN module installs

by hardburn (Abbot)
on May 03, 2004 at 13:17 UTC ( #349997=note: print w/replies, xml ) Need Help??

in reply to Re: Blatant security problem in certain CPAN module installs
in thread Blatant security problem in certain CPAN module installs

This makes these modules completely unsuitable for an unprotected upload to CPAN, as all CPAN testers will then unknowingly download code from the web that is not on the CPAN - a bad situation indeed.

Instead of a full-blown distribution up on CPAN, why not produce a "stub distribution"? It could simply contain the POD and a Makefile.PL/Build.PL that prints out a message saying "this module is just a stub, and the full distro has such and such problems, so get it from this web site if you're still interested". This means that users can still discover the module on CPAN (with full documentation), the namespace is obviously taken for anyone checking, and users of are fully informed of the potential problems of using the module.

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Re: Blatant security problem in certain CPAN module installs
by Corion (Pope) on May 03, 2004 at 13:25 UTC

    That would be an idea... I'm still of two minds about this, as the modules are simply convenience modules that automate the download and build of modules that rely on third party source code.

    The idea is mostly that I have these modules in my Bundle::Corion so an upgrade to a new Perl version becomes less painfull for me. An installation from CPAN becomes thus unlikely for me, as these modules are already modules in my "default" installation. But for other people, this could be an alternative to the PPM route when the PPM is not yet available...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://349997]
[Corion]: But yes, "who started this process" is interesting information :)
[tye]: no, I really believe that "login user" was added as a fundamental bit of info about each process in order to enhance the usefulness of auditing
[Corion]: Ah - if that information is saved in a file, then you could theoretically spam that file and confuse getlogin(). So, don't use it for authentication :)
[tye]: that is what getlogin() certainly *used* to do. I don't believe that is what it certainly should do.
[davido]: /var/run/utmp is 664 i think.
[tye]: Note that my "man getlogin" says that it uses stdin when it should use /dev/tty (calling a glibc bug). But that does not appear to be the case when I test it. But maybe Perl's getlogin() is not using glibc's getlogin().
[oiskuu]: well, run a strace and see what the getlogin does for you.... As I said. SELinux probably has those security labels. But not regular linux.
[tye]: for example, read https://unix. questions/146138/ loginuid-should-be -allowed-to-change -or-not-mutable-or -not
[tye]: I'm not using SELinux and it certainly appears to disagree with you. shrug
[tye]: Since you brought up /proc, oiskuu, I didn't see you respond to my suggestion of 'loginuid'. Does your /proc not have such?

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2017-06-23 19:44 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (554 votes). Check out past polls.