Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Smylers]

Michael G Schwern writes:

> Smylers wrote:
> 
> > > I have lying around a prototype for the CPAN shell to warn the user
> > > when they run it as root and offer to reconfigure itself to only su
> > > for the install.  That would help plug the hole.
> > 
> > Yeah, that sounds good.
> > 
> > But only for users running CPAN, not anybody who is manually un-tar-ing
> > a distribution.  I have no data for this, but I suspect those who do
> > manual installs in this way are also more likely to do the whole thing
> > as root, and less likely to be involved in the Perl community (such as
> > knowing much about Cpan) -- and therefore most likely to get hurt by
> > this, or to pick up a bad impression of Perl or its community as a
> > result.
> 
> Since the perl build process is directly analogous to the autoconf build
> process...

I think the difference is that autoconf-generated software is generally
created on Unix-like OSes, with actual tar commands.  Cpan is different,
in that it's quite reasonable for distributions to've been created on a
system without tar or Unix-like permissions.

>   perl Makefile.PLsh Configure
>   makemake
>   make test   make check
>   sudo make install   sudo make install

Or:

  $ su
  # ./Configure
  # make
  # make install

I don't know how common that is any more.  Most of the people I've seen
doing it were installing Unix software well before sudo gained
widespread popularity, and seem to've got into the habit of running as
root for sys-admin tasks.

But I take your basic point:

> ...this is not a Perl problem but a general lack of basic security
> problem.  An admin should know to run as little as possible as root,
> this is dead basic security.  Anyone who blames Perl for the admin's
> mistake is just looking for someone to blame, so there's little bother
> in trying to convince them otherwise.
> 
> We can only keep an ignorant admin from blowing off their foot for so
> long.  The longer we protect them from their own ignorance the bigger
> the boom is likely to be.

Smylers

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Smylers wrote:
>> I have lying around a prototype for the CPAN shell to warn the user
>> when they run it as root and offer to reconfigure itself to only su
>> for the install.  That would help plug the hole.
> 
> Yeah, that sounds good.
> 
> But only for users running CPAN, not anybody who is manually un-tar-ing
> a distribution.  I have no data for this, but I suspect those who do
> manual installs in this way are also more likely to do the whole thing
> as root, and less likely to be involved in the Perl community (such as
> knowing much about Cpan) -- and therefore most likely to get hurt by
> this, or to pick up a bad impression of Perl or its community as a
> result.

Since the perl build process is directly analogous to the autoconf build
process...

perl Makefile.PLsh Configure
makemake
make test   make check
sudo make install   sudo make install

...this is not a Perl problem but a general lack of basic security problem.
An admin should know to run as little as possible as root, this is dead basic
security.  Anyone who blames Perl for the admin's mistake is just looking for
someone to blame, so there's little bother in trying to convince them otherwise.

We can only keep an ignorant admin from blowing off their foot for so long.
The longer we protect them from their own ignorance the bigger the boom is
likely to be.

It's not Perl's problem, but one can pro-actively educate by adding detection
code to their Makefile.PL and build targets to warn if they're being run as
root and include instructions/points on the proper way to do an installation.
 I will not put this code into MakeMaker, its a feature, but you're welcome to
add it to your own modules and consider it for Module::Build.


-- 
39. Not allowed to ask for the day off due to religious purposes, on the
basis that the world is going to end, more than once.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Jan Dubois wrote:
> On Thu, 13 Nov 2008, Michael G Schwern wrote:
>> This is why I want CPAN to return to its common carrier policy.  Don't 
>> inspect
>> them, don't open them, don't reject them and especially don't try to fix 
>> them,
>> just leave the packages sealed.
> 
> CPAN (at least the indexing part of it) always poked inside the packages and
> verified "ownership" of namespaces.  Do you really want *anybody* to be able
> to upload a new version of your modules and have them replace your versions
> in the index?  If you don't, then you'll have to let go of this "common 
> carrier"
> idea.
> 
> Another "violation" of your common carrier ideal is that PAUSE won't index
> packages with a version number lower than the highest already released one.
> Do you want to get rid of that too?
>
> Finally, there is a difference between what you can upload to CPAN and what
> is being included in the index (although stuff not in the index is of course
> invisible to many CPAN users).

These are all related to how CPAN works or CPAN specific security holes.  Sort
of a "clear and present danger" clause with the added notion that it's a
problem created by CPAN and only PAUSE can solve the problem.

It's sort of like the post office needing to know who it's from and where it's
going... except we put that information on the inside so PAUSE has no choice
but to peek.  And we do it with incorruptible robots.

And these were pragmatic decisions made to get shit done.  They were not done
under the general purpose banner of "Think Of The Children".  Sorry, "Protect
The User".

Namespace spoofing is very clear, real and CPAN specific security problem.
Namespace protection is necessary to prevent a malicious Trojan horse.  It's a
security problem created by CPAN which should be (and can only be) solved by 
CPAN.

The version numbering thing is necessary because the index is limited to
showing just one version.  Are you going to index the latest or the highest?
PAUSE had to make a decision and went with the highest.

The difference between the CPAN index and what's on CPAN is a lamentable part
of how the CPAN index is implemented, it can only show version.  With only one
tool at its disposal, PAUSE has to take an all-or-nothing approach.  If the
index technology were improved to allow a complete index with metadata (what
search.cpan.org effectively does for itself) then we could have a complete
listing with information about the authority of each dist marked in the index.
 That would relieve a lot of problems and give PAUSE a lot of flexibility.


[1]  Someone's going to point out that an independent could create their own
index from a CPAN mirror and publish that, but it's going to fall out of sync.

-- 
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Smylers]

Michael G Schwern writes:

> Smylers wrote:
> 
> > you're talking about Cpan being something morally equivalent to a
> > common carrier, rather than an actual common carrier in the legal
> > sense?
> 
> Yes, because we are not lawyers I don't even want to approach arguing
> about the legal definition.  But there is utility in the idea, as a
> line.  The idea that the carrier is not responsible for the content.

Makes sense.  But I don't think rejecting certain uploads for 

> > The Debian manpage for GNU tar documents this option:
> > 
> >   --no-same-permissions
> >   apply umask to extracted files (the default for non-root
> >   users)
> > 
> > So umask would be ignored for Andreas above because he un-tar-ed as root
> > (and I'm guessing you tried it as you, thereby not triggering the
> > behaviour).
> 
> Yes, I don't even give myself root or su access to avoid accidentally
> forgetting I'm logged in as root.  Everything is through sudo.

Me too.  It just seems much saner all round.

> > Requiring root privs for the last step of installation is common, so
> > I guess it's fairly common for some people to do all the steps as
> > root (however inadvisable that is).
> 
> Well then those users are fucked another dozen ways.

I've seen an alarming number of people do this, and generally get away
with it.

> I have lying around a prototype for the CPAN shell to warn the user
> when they run it as root and offer to reconfigure itself to only su
> for the install.  That would help plug the hole.

Yeah, that sounds good.

But only for users running CPAN, not anybody who is manually un-tar-ing
a distribution.  I have no data for this, but I suspect those who do
manual installs in this way are also more likely to do the whole thing
as root, and less likely to be involved in the Perl community (such as
knowing much about Cpan) -- and therefore most likely to get hurt by
this, or to pick up a bad impression of Perl or its community as a
result.

Smylers

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Smylers wrote:
>> [1] "common carrier" is a legal idea from common US/UK law.  I don't
>> > want to get into the legal mumbo jumbo because we're not lawyers, but
>> > invoking the idea is useful and powerful.
> 
> OK, so you're talking about Cpan being something morally equivalent to a
> common carrier, rather than an actual common carrier in the legal sense?

Yes, because we are not lawyers I don't even want to approach arguing about
the legal definition.  But there is utility in the idea, as a line.  The idea
that the carrier is not responsible for the content.


> The Debian manpage for GNU tar documents this option:
> 
>   --no-same-permissions
>   apply umask to extracted files (the default for non-root users)
> 
> So umask would be ignored for Andreas above because he un-tar-ed as root
> (and I'm guessing you tried it as you, thereby not triggering the
> behaviour).

Yes, I don't even give myself root or su access to avoid accidentally
forgetting I'm logged in as root.  Everything is through sudo.


> Requiring root privs for the last step of installation is common, so I
> guess it's fairly common for some people to do all the steps as root
> (however inadvisable that is).

Well then those users are fucked another dozen ways.

I have lying around a prototype for the CPAN shell to warn the user when they
run it as root and offer to reconfigure itself to only su for the install.
That would help plug the hole.


-- 
"I went to college, which is a lot like being in the Army, except when
 stupid people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Smylers]

Michael G Schwern writes:

> I use the term "common carrier" [1] because it has a very special
> meaning.
>
> [1] "common carrier" is a legal idea from common US/UK law.  I don't
> want to get into the legal mumbo jumbo because we're not lawyers, but
> invoking the idea is useful and powerful.

OK, so you're talking about Cpan being something morally equivalent to a
common carrier, rather than an actual common carrier in the legal sense?

> It is the difference between just transporting sealed packages and
> not.  Once you peek inside them and get involved in their business,
> for whatever reason, you are no longer a common carrier.  This is a
> whole different ball game.

Indeed.  But if Cpan is only _like_ a common carrier, then it never
actually had common carrier protection in law in the first place -- so
surely it can't lose it?

Smylers

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Smylers]

Aristotle Pagaltzis writes:

> * Michael G Schwern <[EMAIL PROTECTED]> [2008-11-13 04:15]:
> 
> > I really, really, really don't want PAUSE modifying my stuff after
> > it's uploaded.
> 
> Count me in this camp.

That's my instinct as well.

> I do think that PAUSE could fix this, but it *MUST* require author
> consent.

Given how few instances of this have been counted, is it worth the
effort for this, rather than just rejecting problems?

> (Needless to mention, once the toolchain is appropriately patched, the
> won’t-index mail should also include the hint that if on Windows, one
> might want to upgrade one’s toolchain to avoid having to deal with
> this hassle.)

Nah, this is Windows -- Pause should just use a rootkit to gain access
to the developer's computer and upgrade the toolchain for him ...

> > Until now CPAN has been a common carrier. Pretty much anything was
> > allowed, stuff was only rejected for extreme reasons and always on a
> > case-by-case basis and always by human judgment.
> 
> The filtering does not change this. It doesn’t cause the upload to be
> rejected.

Also I believe that even proper legal-entity common carriers are
permitted to reject certain classes of things.  The Wikipedia page
mentions postal services declining to tranport money; Royal Mail also
refuses aerosols, batteries, counterfeit currency, dry ice, obscene
publications, foreign lottery tickets ...

Rejecting certain undesirable uploads meeting well-defined criteria is a
long way from modifying stuff in other people's names.

Smylers

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Smylers]

Michael G Schwern writes:

> Andreas J. Koenig wrote:
> 
> > # umask
> > 002
> > # tar xzf 
> > /home/ftp/pub/PAUSE/authors/id/Y/YV/YVES/ExtUtils-Install-1.51.tar.gz 
> > # ls -la ExtUtils-Install-1.51 
> > total 1104
> > -rwxrwxrwx 1  544  5131765 Mar  3  2008 Build.PL*
> 
> Your tar is not honoring umask.  ... What tar is that, btw?  I've
> tried out both BSD and GNU tar.

The Debian manpage for GNU tar documents this option:

  --no-same-permissions
  apply umask to extracted files (the default for non-root users)

So umask would be ignored for Andreas above because he un-tar-ed as root
(and I'm guessing you tried it as you, thereby not triggering the
behaviour).

Requiring root privs for the last step of installation is common, so I
guess it's fairly common for some people to do all the steps as root
(however inadvisable that is).

Smylers

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Aristotle Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2008-11-13 04:15]:
> I really, really, really don't want PAUSE modifying my stuff
> after it's uploaded. Oh god the mysterious bugs. And then
> there's the fact that the code I've put my name and signature
> on is not the same code as is being distributed!

Count me in this camp.

I do think that PAUSE could fix this, but it *MUST* require
author consent. User data is untouchable by principle. The fact
that tarballs are “just an envelope” does not matter; they are no
less part of the user’s data than the extracted contents.

My suggestion on IRC when dmq stumbled into this was that PAUSE
should not index the tarball nor mangle it; but it could produce
a repacked version and include a link to it in the “was not
indexed” mail. That way the author can rubberstamp the repacked
version by pasting the link right back into the URL field in the
PAUSE upload form. Or else they can fix their toolchain on their
own terms and prepare a fresh upload. Or take their ball and go
home. Whatever.

The real fix is to patch the Windows code in EU::MM and M::B so
that tarballs produced through them won’t contain world-writable
files, so that ultimately the whole process would become entirely
transparent to the Windows-based crowd. But in the meantime,
having PAUSE provide assistance (not automagic!) for such people
would be a helpful way of keeping the fuss down.

(Needless to mention, once the toolchain is appropriately
patched, the won’t-index mail should also include the hint that
if on Windows, one might want to upgrade one’s toolchain to avoid
having to deal with this hassle.)

> This security check has sent CPAN on the slippery slope of
> security.

Not hardly.

> Until now CPAN has been a common carrier. Pretty much anything
> was allowed, stuff was only rejected for extreme reasons and
> always on a case-by-case basis and always by human judgment.

The filtering does not change this. It doesn’t cause the upload
to be rejected. It merely causes it not to be indexed, and there
a lots of reasons for which PAUSE will already refuse to index an
upload that it accepts. Checking for world-writable files feels
to me just like the other “is this a sane tarball” tests that are
already being performed. It seems to me like a minor and hardly
objectionable addition – were it not for Windows marching to a
different drummer.

Silently mangling tarballs, in contrast, would be entirely new
territory.


* Jan Dubois <[EMAIL PROTECTED]> [2008-11-13 20:25]:
> CPAN (at least the indexing part of it) always poked inside the
> packages and verified "ownership" of namespaces. Do you really
> want *anybody* to be able to upload a new version of your
> modules and have them replace your versions in the index? If
> you don't, then you'll have to let go of this "common carrier"
> idea.

You are confusing two separate things, which is no surprise
because Michael confused them too. CPAN is two things: a file
distribution mirror network and an indexing service.

The mirror network, so far, distributes the files you put on
there in bit-for-bit identical form, and therefore is in fact a
common carrier.

The indexing service, OTOH, is not. But the author does not get
to touch the index database anyway. All they can do is affect it
in a roundabout way by uploading tarballs for distribution that
the indexer will consider interesting enough to take a look at.

Changing the indexer’s idea of what is interesting or not is not
related to the mirror network’s bit-for-bit identity contract. I
would not want to see the latter change.

Regards,
-- 
Aristotle Pagaltzis // 

RE: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Jan Dubois]

On Thu, 13 Nov 2008, Michael G Schwern wrote:
> This is why I want CPAN to return to its common carrier policy.  Don't inspect
> them, don't open them, don't reject them and especially don't try to fix them,
> just leave the packages sealed.

CPAN (at least the indexing part of it) always poked inside the packages and
verified "ownership" of namespaces.  Do you really want *anybody* to be able
to upload a new version of your modules and have them replace your versions
in the index?  If you don't, then you'll have to let go of this "common carrier"
idea.

Another "violation" of your common carrier ideal is that PAUSE won't index
packages with a version number lower than the highest already released one.
Do you want to get rid of that too?

Finally, there is a difference between what you can upload to CPAN and what
is being included in the index (although stuff not in the index is of course
invisible to many CPAN users).

Cheers,
-Jan

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Andreas J. Koenig wrote:
>  > Most systems already do this by default, because it's good security
>  > practice. If you don't have a umask set, that's a basic
>  > vulnerability *at the user's end*. No amount of hand-holding from
>  > CPAN will protect the user without a umask. Some other system will
>  > ship a world writable file or a setuid executable or something.
>  > Then you're hosed all over again.
> 
> You are not well informed.
> 
> # umask
> 002
> # tar xzf 
> /home/ftp/pub/PAUSE/authors/id/Y/YV/YVES/ExtUtils-Install-1.51.tar.gz 
> # ls -la ExtUtils-Install-1.51 
> total 1104
> drwxrwxrwx 4  544  5134096 Nov 12 20:02 ./
> drwxrwxrwt 10110 root root 1073152 Nov 13 08:24 ../
> -rwxrwxrwx 1  544  5131765 Mar  3  2008 Build.PL*
> -rwxrwxrwx 1  544  5138911 Nov 12 19:58 Changes*
> -rwxrwxrwx 1  544  513 197 Sep 10  2007 INSTALL.SKIP*
> -rwxrwxrwx 1  544  513 446 Nov  5 21:51 MANIFEST*
> -rwxrwxrwx 1  544  513 458 Sep 10  2007 MANIFEST.SKIP*
> -rwxrwxrwx 1  544  513 743 Nov 12 20:02 META.yml*
> -rwxrwxrwx 1  544  5132506 Mar  3  2008 Makefile.PL*
> -rwxrwxrwx 1  544  5131282 Sep 10  2007 README*
> drwxrwxrwx 3  544  5134096 Nov 12 20:01 lib/
> drwxrwxrwx 3  544  5134096 Nov 12 20:01 t/

Your tar is not honoring umask.  I consider that the security problem, not the
archive.  Fixing the archive only hides the real problem, because that user is
going to download another archive from somewhere else and it's not going to be
protected.

What tar is that, btw?  I've tried out both BSD and GNU tar.


>  > We are trying to fix a basic, wide-spread, user-end security hole, one 
> that is
>  > not at all specific to Perl, at too high a level and too specific a system.
> 
> It's not wide spread, it's only coming frrom a handful of Windows
> users and we have to react some way or another. Doing nothing is not
> an option.

I was referring to the lack of umask protection on the system extracting the
archive.  If you don't have that, you're hosed a dozen ways far more serious
than any of this.

I guess this is where we fundamentally disagree.  I see fixing the archive as
not having a real impact on the user's security, because the hole is still
there, and thus not worth risking CPAN's common carrier status.


>  > It's like plugging one hole in a screen door.
> 
> Pfff, there's no arguing about the minitude of the achievement per se.
> I'm much more annoyed by your intervention than I'm already annoyed by
> the mere fact that we have to fritter away our time with such a
> stupidity.

I'm sorry to kick up a fuss, but I believe it's really important that CPAN
remain a common carrier.  See my earlier post to Yves about that.

Granted I think I lost a bit of perspective and forgot that it's only the
indexer that's rejecting the file, it's still on CPAN.  The idea of PAUSE
modifying the file is what got me wound up.


-- 
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

demerphq wrote:
>> I really, really, really don't want PAUSE modifying my stuff after it's
>> uploaded.  Oh god the mysterious bugs.  And then there's the fact that the
>> code I've put my name and signature on is not the same code as is being
>> distributed!  That's a trust violation as well as maybe a license violation.
> 
> Oh please, save me the drama. We aren't talking about modifying "your
> stuff" we are talking about twiddling some bits in a tar file.

I use the term "common carrier" [1] because it has a very special meaning.  It
is the difference between just transporting sealed packages and not.  Once you
peek inside them and get involved in their business, for whatever reason, you
are no longer a common carrier.  This is a whole different ball game.

What a common carrier says is they are responsible for moving things from
point A to point B and that's that.  They're not responsible for what's inside
the package.  They're not responsible for if it works, what you do with it or
even if the contents are legal.  Shipping companies, telcos, Internet
providers, postal services... these are all (or should be) common carriers.
They don't peek inside your package/conversation/packets/mail, no matter what
the good intentions, and they'll take all comers.

As soon as they do, as soon as they take it upon themselves to inspect the
contents, whether to accept some and reject others or to "fix" problems or
whatever, they take on responsibility for those contents.  Their role has
change and become much more complicated.  The relationship between the sender
and the carrier has also changed and become much more complicated.

This is why you used to never have to worry about a US phone company listening
on your calls (except with a government mandated wire tap), because if they
did they'd lose their common carrier status and suddenly have a crapload of
extra, expensive, responsibility.  Once they lose that status, or if they
never had it in the first place (common carrier status for Internet providers
is not clear), they'll monkey with your packets all they want.  Now they
monitor and traffic shape to their heart's content.  This slope is very
slippery and very steep, but it has a very clear edge and CPAN has crossed it.

This is why I want CPAN to return to its common carrier policy.  Don't inspect
them, don't open them, don't reject them and especially don't try to fix them,
just leave the packages sealed.


> And if you really do want to be picky about this, then it could be
> voluntary as was already suggested.
> 
> Then when PAUSE bounces my package it can say "We've rejected your
> package for blah blah blah, but we can fix it for you if you visit
> this [link], or if you reupload a new package with SPECIALFLAG set in
> the FNORBLE file."

Why are we fixing this at PAUSE at all?  You can do this with the right tar
flags.  What's the next subtle, cross-platform problem that PAUSE is supposed
to fix for you?

I already said I'd consider a MakeMaker patch to automatically strip world
write bits on Windows, but I don't think one ever materialized.  If it did and
I missed it I apologize, but I really don't consider this to be an urgent issue.


>> They will be well intentioned and they will add complications and generate
>> false negatives and get in people's way and continue to erode CPAN's policy 
>> of
>> being a common carrier.
>>
>> Now that the CPAN shells and archiving modules are handling it at their end, 
>> I
>> think the PAUSE filter should be removed.  It's not PAUSE's job to be the 
>> code
>> police.
> 
> I agree with this. However we are where we are, and PAUSE fixing the
> package in a way that doesn't require windows users to get annoyed is
> a good solution.

We are not stuck "where we are".  The PAUSE check is security theater and can
simply be removed.


[1] "common carrier" is a legal idea from common US/UK law.  I don't want to
get into the legal mumbo jumbo because we're not lawyers, but invoking the
idea is useful and powerful.


-- 
54. "Napalm sticks to kids" is *not* a motivational phrase.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Andreas J. Koenig]

> On Wed, 12 Nov 2008 20:44:45 -0800, Michael G Schwern <[EMAIL PROTECTED]> 
> said:

 > Andreas J. Koenig wrote:
 >>> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern <[EMAIL 
 >>> PROTECTED]> said:
 >> 
 >> > Now that the CPAN shells and archiving modules are handling it at their 
 >> > end, I
 >> > think the PAUSE filter should be removed.  It's not PAUSE's job to be the 
 >> > code
 >> > police.
 >> 
 >> It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell
 >> and archiving module involved.

 > What I was expressing is that the CPAN shell can do

I know very well what the cpan shell can do, but it cannot replace tar.

 > the twiddling to strip
 > flags at the point of extraction, rather than PAUSE stopping it at the gate.
 > Archive::Tar already does this (see $Archive::Tar::INSECURE_EXTRACT_MODE).
 > The important distinction being that it's done under the user's control and
 > not by PAUSE fiat.

I don't care what the users do under their control. I care that they
do not get hosed by the perl community.

 > PAUSE shouldn't be playing security nanny or any other nanny.

PAUSE is innocent and shall remain so. But when the perl community
does not enough to protect the innocent user from stupid packaging
some sort of action is required. We can find alternative ways of
dealing with it but we are responsible for avoiding harm to the
innocent.

 > It's not even necessary or effective.  Because there's already a perfectly
 > sensible and universal way to avoid this problem and that's to set your umask
 > to something sensible.  Then no matter what the archive's internal 
 > permissions
 > are set to they'll be stripped when it's extracted.

Hear, hear. I tell you again, I don't care what the users do under
their control. I care that they do not get hosed by the perl
community.

 > Most systems already do this by default, because it's good security
 > practice. If you don't have a umask set, that's a basic
 > vulnerability *at the user's end*. No amount of hand-holding from
 > CPAN will protect the user without a umask. Some other system will
 > ship a world writable file or a setuid executable or something.
 > Then you're hosed all over again.

You are not well informed.

# umask
002
# tar xzf /home/ftp/pub/PAUSE/authors/id/Y/YV/YVES/ExtUtils-Install-1.51.tar.gz 
# ls -la ExtUtils-Install-1.51 
total 1104
drwxrwxrwx 4  544  5134096 Nov 12 20:02 ./
drwxrwxrwt 10110 root root 1073152 Nov 13 08:24 ../
-rwxrwxrwx 1  544  5131765 Mar  3  2008 Build.PL*
-rwxrwxrwx 1  544  5138911 Nov 12 19:58 Changes*
-rwxrwxrwx 1  544  513 197 Sep 10  2007 INSTALL.SKIP*
-rwxrwxrwx 1  544  513 446 Nov  5 21:51 MANIFEST*
-rwxrwxrwx 1  544  513 458 Sep 10  2007 MANIFEST.SKIP*
-rwxrwxrwx 1  544  513 743 Nov 12 20:02 META.yml*
-rwxrwxrwx 1  544  5132506 Mar  3  2008 Makefile.PL*
-rwxrwxrwx 1  544  5131282 Sep 10  2007 README*
drwxrwxrwx 3  544  5134096 Nov 12 20:01 lib/
drwxrwxrwx 3  544  5134096 Nov 12 20:01 t/


 > We are trying to fix a basic, wide-spread, user-end security hole, one that 
 > is
 > not at all specific to Perl, at too high a level and too specific a system.

It's not wide spread, it's only coming frrom a handful of Windows
users and we have to react some way or another. Doing nothing is not
an option.

 > It's like plugging one hole in a screen door.

Pfff, there's no arguing about the minitude of the achievement per se.
I'm much more annoyed by your intervention than I'm already annoyed by
the mere fact that we have to fritter away our time with such a
stupidity.


-- 
andreas

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Cosimo Streppone]

On Thu, 13 Nov 2008 05:12:33 +0100, Andreas J. Koenig  
<[EMAIL PROTECTED]> wrote:


On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern  
<[EMAIL PROTECTED]> said:


> Now that the CPAN shells and archiving modules are handling it at  
their end, I
> think the PAUSE filter should be removed.  It's not PAUSE's job to be  
the code

> police.

It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell
and archiving module involved.


This is why I started the thread proposing to patch EU-MM
to change the default tar command line *on Windows*.

It will take time to upgrade anyone, yes.

But we don't need anyone, we only need those few Windows
users who develop their CPAN stuff on Windows.

--
Cosimo

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Andreas J. Koenig]

> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern <[EMAIL PROTECTED]> 
> said:

  > Now that the CPAN shells and archiving modules are handling it at their 
end, I
  > think the PAUSE filter should be removed.  It's not PAUSE's job to be the 
code
  > police.

It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell
and archiving module involved.

-- 
andreas

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Andreas J. Koenig]

> On Wed, 12 Nov 2008 14:51:26 -0600, Jonathan Rockway <[EMAIL PROTECTED]> 
> said:

  > I agree with demerphq here, why can't PAUSE just fix this?

It didn't come up in the hasty discussion about this problem, it
didn't occur to me for a moment. And to nobody else. And the number of
victims seemed to be low. I'm watching the number of rejects every day
and I have counted 50 since Sep 23rd, so exactly one per day on
average.

I will probably take the time implement the suggestion, but can't
promise it at the moment.

  > It won't
  > break signatures (since they sign file content, not file metadata), and
  > it won't break the CHECKSUMS file (since that could be generated after
  > the tarball is fixed).

It seems you're right.

  > It could be weird if what you upload to CPAN isn't what you
  > download... but it fixes a security problem, and it doesn't require
  > authors to know that this problem exists.  Abstraction++

(demerphq,jrockway)++

-- 
andreas

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Shlomi Fish]

On Thursday 13 November 2008, David Golden wrote:
> On Thu, Nov 13, 2008 at 3:39 AM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> >> What I was expressing is that the CPAN shell can do the twiddling to
> >> strip flags at the point of extraction, rather than PAUSE stopping it at
> >> the gate. Archive::Tar already does this (see
> >> $Archive::Tar::INSECURE_EXTRACT_MODE).
> >
> > Archive::Tar does, but Archive::Extract (which CPANPLUS uses) doesn't.
>
> It was a bug.  Addressed in 0.28 as a result of these discussions.
> The next non-development release of CPANPLUS will use the new
> Archive::Extract and close the security hole under discussion.
>

This bug still exists in Archive-Extract-0.28. See my comment at the end of:

http://rt.cpan.org/Ticket/Display.html?id=39554

One needs to also set $Archive::Tar::CHMOD .

Regards,

Shlomi Fish


-- 
-
Shlomi Fish   http://www.shlomifish.org/
Funny Anti-Terrorism Story - http://xrl.us/bjn7t

Shlomi, so what are you working on? Working on a new wiki about unit testing 
fortunes in freecell? -- Ran Eilam

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[David Golden]

On Thu, Nov 13, 2008 at 3:39 AM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
>> What I was expressing is that the CPAN shell can do the twiddling to strip
>> flags at the point of extraction, rather than PAUSE stopping it at the
>> gate. Archive::Tar already does this (see
>> $Archive::Tar::INSECURE_EXTRACT_MODE).
>
> Archive::Tar does, but Archive::Extract (which CPANPLUS uses) doesn't.

It was a bug.  Addressed in 0.28 as a result of these discussions.
The next non-development release of CPANPLUS will use the new
Archive::Extract and close the security hole under discussion.

-- David

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Shlomi Fish]

On Thursday 13 November 2008, Michael G Schwern wrote:
> Andreas J. Koenig wrote:
> >> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern
> >> <[EMAIL PROTECTED]> said:
> >   >
> >   > Now that the CPAN shells and archiving modules are handling it at
> >   > their end, I think the PAUSE filter should be removed.  It's not
> >   > PAUSE's job to be the code police.
> >
> > It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell
> > and archiving module involved.
>
> What I was expressing is that the CPAN shell can do the twiddling to strip
> flags at the point of extraction, rather than PAUSE stopping it at the
> gate. Archive::Tar already does this (see
> $Archive::Tar::INSECURE_EXTRACT_MODE).

Archive::Tar does, but Archive::Extract (which CPANPLUS uses) doesn't.

> The important distinction being that 
> it's done under the user's control and not by PAUSE fiat.  PAUSE shouldn't
> be playing security nanny or any other nanny.
>
> It's not even necessary or effective.  Because there's already a perfectly
> sensible and universal way to avoid this problem and that's to set your
> umask to something sensible.  Then no matter what the archive's internal
> permissions are set to they'll be stripped when it's extracted.

I already have a sensible umask. However, CPANPLUS ignores it and sets the 
permissions to be world-writable. See these bugs:

* http://rt.cpan.org/Ticket/Display.html?id=39516

* http://rt.cpan.org/Ticket/Display.html?id=39554

>
> Most systems already do this by default, because it's good security
> practice. If you don't have a umask set, that's a basic vulnerability *at
> the user's end*.  No amount of hand-holding from CPAN will protect the user
> without a umask.  Some other system will ship a world writable file or a
> setuid executable or something.  Then you're hosed all over again.
>
> We are trying to fix a basic, wide-spread, user-end security hole, one that
> is not at all specific to Perl, at too high a level and too specific a
> system.
>
> It's like plugging one hole in a screen door.

It's not necessarily a problem at the user-end, because CPANPLUS ignores the 
(secure) umask I set and still sets the permissions to 666 or 777.

Regards,

Shlomi Fish

-
Shlomi Fish   http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html

Shlomi, so what are you working on? Working on a new wiki about unit testing 
fortunes in freecell? -- Ran Eilam

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[demerphq]

2008/11/13 chromatic <[EMAIL PROTECTED]>:
> On Wednesday 12 November 2008 22:36:31 demerphq wrote:
>
>> > I really, really, really don't want PAUSE modifying my stuff after it's
>> > uploaded.  Oh god the mysterious bugs.  And then there's the fact that
>> > the code I've put my name and signature on is not the same code as is
>> > being distributed!  That's a trust violation as well as maybe a license
>> > violation.
>
>> Oh please, save me the drama. We aren't talking about modifying "your
>> stuff" we are talking about twiddling some bits in a tar file.
>
> I can only think of several ways that could possibly go wrong.

Pray tell, what are they?

> I understand why PAUSE enforces the policy that it won't index anything it
> can't index, but I don't understand what permission bits that may or may not
> be set have to do with indexing.
>
> I realize the longstanding Perl cultural view of encapsulation is, to put it
> mildly, highly voluntary -- but the first time I catch a naked, drunk
> neighbor rifling through my closet is the last time any naked, drunk neighbor
> rifles through my closet, regardless of sincerity of intent.

So you equate PAUSE unpacking the tar file, chmod'ing to not be world
writable and then retarring it to a naked drunk neighbor rifling
through your closet? I don't get it really, and I'm wondering what
kind of neighborhood you live in!. And presumably this would never
happen to you right? Being a switched on unix guy you wouldnt roll a
world writable CPAN package anyway would you?

If there is any comparison its like the library putting durable
binding and a security strip on a book before it hits the shelves.

Cheers,
yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[chromatic]

On Wednesday 12 November 2008 22:36:31 demerphq wrote:

> > I really, really, really don't want PAUSE modifying my stuff after it's
> > uploaded.  Oh god the mysterious bugs.  And then there's the fact that
> > the code I've put my name and signature on is not the same code as is
> > being distributed!  That's a trust violation as well as maybe a license
> > violation.

> Oh please, save me the drama. We aren't talking about modifying "your
> stuff" we are talking about twiddling some bits in a tar file.

I can only think of several ways that could possibly go wrong.

I understand why PAUSE enforces the policy that it won't index anything it 
can't index, but I don't understand what permission bits that may or may not 
be set have to do with indexing.

I realize the longstanding Perl cultural view of encapsulation is, to put it 
mildly, highly voluntary -- but the first time I catch a naked, drunk 
neighbor rifling through my closet is the last time any naked, drunk neighbor 
rifles through my closet, regardless of sincerity of intent.

-- c

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[demerphq]

2008/11/13 Michael G Schwern <[EMAIL PROTECTED]>:
> Jonathan Rockway wrote:
>> * On Wed, Nov 12 2008, David Golden wrote:
>>> On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
 IMO if the toolchain is to work this should happen at PAUSE (if it can
 detect this problem IMO it should just damn well fix it itself) or at
 extraction.
>>> It *is* being fixed at extraction.  But it requires people to upgrade
>>> CPAN and CPANPLUS (maybe Archive::Extract as well).  It was a faster
>>> fix to close the PAUSE indexing door than to get those fixes released.
>>
>> I agree with demerphq here, why can't PAUSE just fix this?  It won't
>> break signatures (since they sign file content, not file metadata),
>
> Maybe they should start signing the metadata then!
>
>
>> and
>> it won't break the CHECKSUMS file (since that could be generated after
>> the tarball is fixed).
>>
>> It could be weird if what you upload to CPAN isn't what you
>> download... but it fixes a security problem, and it doesn't require
>> authors to know that this problem exists.  Abstraction++
>
> -100_000_000
>
> I really, really, really don't want PAUSE modifying my stuff after it's
> uploaded.  Oh god the mysterious bugs.  And then there's the fact that the
> code I've put my name and signature on is not the same code as is being
> distributed!  That's a trust violation as well as maybe a license violation.

Oh please, save me the drama. We aren't talking about modifying "your
stuff" we are talking about twiddling some bits in a tar file.

Bits in a tar file mind you that mean nothing to the system that the
tar file was created on.

And if you really do want to be picky about this, then it could be
voluntary as was already suggested.

Then when PAUSE bounces my package it can say "We've rejected your
package for blah blah blah, but we can fix it for you if you visit
this [link], or if you reupload a new package with SPECIALFLAG set in
the FNORBLE file."

> This security check has sent CPAN on the slippery slope of security.  Until
> now CPAN has been a common carrier.  Pretty much anything was allowed, stuff
> was only rejected for extreme reasons and always on a case-by-case basis and
> always by human judgment.  Now we've put in an automatic filter to reject some
> vaguely insecure code.  CPAN is no longer a common carrier.  Once that line
> has been crossed, all sorts of attempts will be made to add more filtering,
> such as the suggestion above.
>
> They will be well intentioned and they will add complications and generate
> false negatives and get in people's way and continue to erode CPAN's policy of
> being a common carrier.
>
> Now that the CPAN shells and archiving modules are handling it at their end, I
> think the PAUSE filter should be removed.  It's not PAUSE's job to be the code
> police.

I agree with this. However we are where we are, and PAUSE fixing the
package in a way that doesn't require windows users to get annoyed is
a good solution.

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Andreas J. Koenig wrote:
>> On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern <[EMAIL 
>> PROTECTED]> said:
> 
>   > Now that the CPAN shells and archiving modules are handling it at their 
> end, I
>   > think the PAUSE filter should be removed.  It's not PAUSE's job to be the 
> code
>   > police.
> 
> It is 'tar xzf CPANFILE.tar.gz' which is exploitable. No CPAN shell
> and archiving module involved.

What I was expressing is that the CPAN shell can do the twiddling to strip
flags at the point of extraction, rather than PAUSE stopping it at the gate.
Archive::Tar already does this (see $Archive::Tar::INSECURE_EXTRACT_MODE).
The important distinction being that it's done under the user's control and
not by PAUSE fiat.  PAUSE shouldn't be playing security nanny or any other 
nanny.

It's not even necessary or effective.  Because there's already a perfectly
sensible and universal way to avoid this problem and that's to set your umask
to something sensible.  Then no matter what the archive's internal permissions
are set to they'll be stripped when it's extracted.

Most systems already do this by default, because it's good security practice.
 If you don't have a umask set, that's a basic vulnerability *at the user's
end*.  No amount of hand-holding from CPAN will protect the user without a
umask.  Some other system will ship a world writable file or a setuid
executable or something.  Then you're hosed all over again.

We are trying to fix a basic, wide-spread, user-end security hole, one that is
not at all specific to Perl, at too high a level and too specific a system.

It's like plugging one hole in a screen door.


-- 
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

David Golden wrote:
> On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
>> I rather strongly object to this change.
> 
> I totally understand -- but keep in mind that this was in response to
> someone flagging this as a potential (if highly unlikely) security
> hole, forwarding it to some security-watchdog site, etc.  So the rapid
> response was "close the hole so no one can say CPAN creates a security
> risk".  (Other than the usual, obvious one of running arbitrary
> code...)
> 
> So it causes some pain, but in my view, it's in the interest of the
> Perl community to be seen as vigilant.

I'm sorry, you'll have to remove your shoes before you can post to this
mailing list.

http://en.wikipedia.org/wiki/Security_theater


-- 
Stabbing you in the face for your own good.

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Jonathan Rockway wrote:
> * On Wed, Nov 12 2008, David Golden wrote:
>> On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
>>> IMO if the toolchain is to work this should happen at PAUSE (if it can
>>> detect this problem IMO it should just damn well fix it itself) or at
>>> extraction.
>> It *is* being fixed at extraction.  But it requires people to upgrade
>> CPAN and CPANPLUS (maybe Archive::Extract as well).  It was a faster
>> fix to close the PAUSE indexing door than to get those fixes released.
> 
> I agree with demerphq here, why can't PAUSE just fix this?  It won't
> break signatures (since they sign file content, not file metadata),

Maybe they should start signing the metadata then!


> and
> it won't break the CHECKSUMS file (since that could be generated after
> the tarball is fixed).
> 
> It could be weird if what you upload to CPAN isn't what you
> download... but it fixes a security problem, and it doesn't require
> authors to know that this problem exists.  Abstraction++

-100_000_000

I really, really, really don't want PAUSE modifying my stuff after it's
uploaded.  Oh god the mysterious bugs.  And then there's the fact that the
code I've put my name and signature on is not the same code as is being
distributed!  That's a trust violation as well as maybe a license violation.

This security check has sent CPAN on the slippery slope of security.  Until
now CPAN has been a common carrier.  Pretty much anything was allowed, stuff
was only rejected for extreme reasons and always on a case-by-case basis and
always by human judgment.  Now we've put in an automatic filter to reject some
vaguely insecure code.  CPAN is no longer a common carrier.  Once that line
has been crossed, all sorts of attempts will be made to add more filtering,
such as the suggestion above.

They will be well intentioned and they will add complications and generate
false negatives and get in people's way and continue to erode CPAN's policy of
being a common carrier.

Now that the CPAN shells and archiving modules are handling it at their end, I
think the PAUSE filter should be removed.  It's not PAUSE's job to be the code
police.


-- 
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Jonathan Rockway]

* On Wed, Nov 12 2008, David Golden wrote:
> On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
>> IMO if the toolchain is to work this should happen at PAUSE (if it can
>> detect this problem IMO it should just damn well fix it itself) or at
>> extraction.
>
> It *is* being fixed at extraction.  But it requires people to upgrade
> CPAN and CPANPLUS (maybe Archive::Extract as well).  It was a faster
> fix to close the PAUSE indexing door than to get those fixes released.

I agree with demerphq here, why can't PAUSE just fix this?  It won't
break signatures (since they sign file content, not file metadata), and
it won't break the CHECKSUMS file (since that could be generated after
the tarball is fixed).

It could be weird if what you upload to CPAN isn't what you
download... but it fixes a security problem, and it doesn't require
authors to know that this problem exists.  Abstraction++

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[demerphq]

2008/11/12 David Golden <[EMAIL PROTECTED]>:
> On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
>> I rather strongly object to this change.
>
> I totally understand -- but keep in mind that this was in response to
> someone flagging this as a potential (if highly unlikely) security
> hole, forwarding it to some security-watchdog site, etc.  So the rapid
> response was "close the hole so no one can say CPAN creates a security
> risk".  (Other than the usual, obvious one of running arbitrary
> code...)
>
> So it causes some pain, but in my view, it's in the interest of the
> Perl community to be seen as vigilant.

Ah well fair enough. Writing my rant was cathartic. :-)

>> this silly test. What really gets me going tho is I WASNT TOLD THIS
>> ABOUT 1.51_01 or 1.51_02 or 1.51_03 or (do you detect a pattern here?)
>> 1.51_04 or 1.51_05, all of which i uploaded in the last few days in
>> the exact same way!!!
>
> That's kind of a loophole, since development versions aren't indexed.
> I think any upload that fails a security test should probably be
> rejected, whether development or full release.

Or at least the author should be notified about it.

>> IMO if the toolchain is to work this should happen at PAUSE (if it can
>> detect this problem IMO it should just damn well fix it itself) or at
>> extraction.
>
> It *is* being fixed at extraction.  But it requires people to upgrade
> CPAN and CPANPLUS (maybe Archive::Extract as well).  It was a faster
> fix to close the PAUSE indexing door than to get those fixes released.

Just curious whats wrong with PAUSE repacking the file with the required perms?

>> Whats going to happen next, stuff rejected because they don't have
>> *nix line endings? Or *nix style shebangs? Or use perl-qa's preferred
>> indentation style or something? H?!
>
> Maybe instead, at a minimum, every distribution should be run against
> Perl::Critic at severity level 4 and anything that doesn't pass should
> be rejected as well.  ;-)
>
> (THAT'S A JOKE, PEOPLE!)
>
>> /g
>
> Right there with you, except my "/grrr" was back when the "security
> alert" got sent off to the watchdogs while the discussion was still
> going on as to whether this was a significant risk in the first place.

Ah, yes I can imagine that being worth a /grrr or two.

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[David Golden]

On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote:
> I rather strongly object to this change.

I totally understand -- but keep in mind that this was in response to
someone flagging this as a potential (if highly unlikely) security
hole, forwarding it to some security-watchdog site, etc.  So the rapid
response was "close the hole so no one can say CPAN creates a security
risk".  (Other than the usual, obvious one of running arbitrary
code...)

So it causes some pain, but in my view, it's in the interest of the
Perl community to be seen as vigilant.

> this silly test. What really gets me going tho is I WASNT TOLD THIS
> ABOUT 1.51_01 or 1.51_02 or 1.51_03 or (do you detect a pattern here?)
> 1.51_04 or 1.51_05, all of which i uploaded in the last few days in
> the exact same way!!!

That's kind of a loophole, since development versions aren't indexed.
I think any upload that fails a security test should probably be
rejected, whether development or full release.

> IMO if the toolchain is to work this should happen at PAUSE (if it can
> detect this problem IMO it should just damn well fix it itself) or at
> extraction.

It *is* being fixed at extraction.  But it requires people to upgrade
CPAN and CPANPLUS (maybe Archive::Extract as well).  It was a faster
fix to close the PAUSE indexing door than to get those fixes released.

> Whats going to happen next, stuff rejected because they don't have
> *nix line endings? Or *nix style shebangs? Or use perl-qa's preferred
> indentation style or something? H?!

Maybe instead, at a minimum, every distribution should be run against
Perl::Critic at severity level 4 and anything that doesn't pass should
be rejected as well.  ;-)

(THAT'S A JOKE, PEOPLE!)

> /g

Right there with you, except my "/grrr" was back when the "security
alert" got sent off to the watchdogs while the discussion was still
going on as to whether this was a significant risk in the first place.

-- David

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[demerphq]

2008/10/1 Andreas J. Koenig <[EMAIL PROTECTED]>:
>> On Tue, 30 Sep 2008 17:11:00 -0500, Jonathan Rockway <[EMAIL PROTECTED]> 
>> said:
>
>  >> Anyway, I think the average CPAN author doesn't
>  >> really know or care about that, sadly.
>  >> See also
>
>  > FWIW, this is true.  I have never thought about it.
>
>  > Personally, I am confused as to why users have programs that do whatever
>  > an input file from the Internet tells them to do.  If you don't want
>  > your tar command to create world-writable files, you should probably
>  > tell your tar command to not create world-writable files... right?  That
>  > is much easier than convincing every person on the Internet to do what
>  > you want.  It is also easier than convincing every CPAN author to
>  > upgrade MakeMaker.
>
> Not true. The tools we are advocating must simply work. If they would
> leave all decisions to the end user we would have no CPAN. MakeMaker
> has always done the right thing, no need to upgrade. There was a bug
> to squash and not to paint over it or bathe in ignorance. Did you even
> notice the bug in the noise?



I rather strongly object to this change.

I just uploaded ExtUtils-Install 1.51, and was rudely told it would
not be indexed. I then spent 15 minutes trying to figure out what
win32 permissions would allow me to create a tarball that would pass
this silly test. What really gets me going tho is I WASNT TOLD THIS
ABOUT 1.51_01 or 1.51_02 or 1.51_03 or (do you detect a pattern here?)
1.51_04 or 1.51_05, all of which i uploaded in the last few days in
the exact same way!!!

IMO if the toolchain is to work this should happen at PAUSE (if it can
detect this problem IMO it should just damn well fix it itself) or at
extraction. It shouldn't be my problem how you nixy people (and I'm
one these days myself) want your files permissioned when they are
installed, especially if those permissions don't make sense on my box
(of the moment) anyway. And at the very least I should find out about
this when I upload a dev release and not be surprised when I make a
production release.

Whats going to happen next, stuff rejected because they don't have
*nix line endings? Or *nix style shebangs? Or use perl-qa's preferred
indentation style or something? H?!

/g



ps: Andreas, don't take this personally I'm just letting off steam and
I still think you are a really nice guy and do a fantastic job with
PAUSE.  :-)
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Andreas J. Koenig]

> On Tue, 30 Sep 2008 17:11:00 -0500, Jonathan Rockway <[EMAIL PROTECTED]> 
> said:

 >> Anyway, I think the average CPAN author doesn't
 >> really know or care about that, sadly.
 >> See also

  > FWIW, this is true.  I have never thought about it.

  > Personally, I am confused as to why users have programs that do whatever
  > an input file from the Internet tells them to do.  If you don't want
  > your tar command to create world-writable files, you should probably
  > tell your tar command to not create world-writable files... right?  That
  > is much easier than convincing every person on the Internet to do what
  > you want.  It is also easier than convincing every CPAN author to
  > upgrade MakeMaker.

Not true. The tools we are advocating must simply work. If they would
leave all decisions to the end user we would have no CPAN. MakeMaker
has always done the right thing, no need to upgrade. There was a bug
to squash and not to paint over it or bathe in ignorance. Did you even
notice the bug in the noise?

-- 
andreas

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Jonathan Rockway]

* On Sun, Sep 28 2008, Cosimo Streppone wrote:
> Hi!
>
> I don't know if I really understand the entire
> "world-writable files" security hole.
>
> Anyway, I think the average CPAN author doesn't
> really know or care about that, sadly.
> See also

FWIW, this is true.  I have never thought about it.

Personally, I am confused as to why users have programs that do whatever
an input file from the Internet tells them to do.  If you don't want
your tar command to create world-writable files, you should probably
tell your tar command to not create world-writable files... right?  That
is much easier than convincing every person on the Internet to do what
you want.  It is also easier than convincing every CPAN author to
upgrade MakeMaker.

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Shlomi Fish]

On Monday 29 September 2008, Aristotle Pagaltzis wrote:
> * Cosimo Streppone <[EMAIL PROTECTED]> [2008-09-29 02:10]:
> > but it seems that gnu tar doesn't like the following:
> >
> >   $ tar --mode=0755 cvf blah.tar somedir
> >   $ tar c --mode=0755 vf blah.tar somedir
> >
> > and will only accept:
> >
> >   $ tar cvf blah.tar --mode=0755 somedir
> >
> > Could this work?
>
> GNU tar will, however, accept this:
>
> tar cv --mode=0755 -f foo.tar bar/
>
> BSD tar will also accept this placement of the `-f` flag,
> according to the man page. Other tars may not, though I don’t
> think that is very likely.
>
> However, the `--mode` switch is a GNU curiosity. No other tar
> that I checked does have it.
>
> Honestly, though, if you are using tar on Windows, I don’t know
> why you would want any other default. Patching EU::MM is the
> pragmatic approach, and we probably can’t avoid it, but I think
> it is the wrong place to fix this, still.
>

Wouldn't setting TAR_OPTIONS on Windows be a better solution?

http://www.linuxtopia.org/online_books/linux_tool_guides/tar_user_guide/using-tar-options.html

Regards,

Shlomi Fish

-
Shlomi Fish   http://www.shlomifish.org/
"The Human Hacking Field Guide" - http://xrl.us/bjn8q

Shlomi, so what are you working on? Working on a new wiki about unit testing 
fortunes in freecell? -- Ran Eilam

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Cosimo Streppone]

På Tue, 30 Sep 2008 04:05:51 +0200, skrev Michael G Schwern  
<[EMAIL PROTECTED]>:



Aristotle Pagaltzis wrote:



[...]
The idea was to relieve Windows users from having to hack their tar  
before they

can use EU::MM to bake distros that the CPAN indexer will not
reject.


Allow me to clarify.  I'm fine with putting in code to help Windows  
users deal with the world writable issue, that's the work around I was  
referring to.

[...]
I've kind of lost track of what's being proposed by whom.


Ok, Aristotle is right. The point of the patch I proposed was:

1) making sure no CPAN author (with a reasonably updated toolchain)
   will need to deal with the unexpected PAUSE indexing failure;

2) avoid hacking tar.(exe|bat) on Windows;

3) to break nothing.

Now I understand that my patch was crappy.
Probably the changes only need to live into `MM_Win32.pm'...

--
Cosimo

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Aristotle Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 16:35]:
>> Aristotle Pagaltzis wrote:
>>> * Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 14:50]:
 MakeMaker can set a minimum umask if it wants to play
 security nanny
>>> On Windows?
>> Windows, as always, is a "special" case. If a work around is
>> necessary for Windows that's fine.
> 
> Err, the *only* point of this patch is Windows. The idea was to
> relieve Windows users from having to hack their tar before they
> can use EU::MM to bake distros that the CPAN indexer will not
> reject.
> 
> If you propose a “better solution” that doesn’t work on Windows
> then it might be “better” but it fails to be a “solution.”

Allow me to clarify.  I'm fine with putting in code to help Windows users deal
with the world writable issue, that's the work around I was referring to.
This is in contrast to adding in code to strip out the world-writable flag on
Unix, which has perfectly fine facilities to deal with that across the board.

I've kind of lost track of what's being proposed by whom.


-- 
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Aristotle Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 16:35]:
> Aristotle Pagaltzis wrote:
> > * Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 14:50]:
> >> MakeMaker can set a minimum umask if it wants to play
> >> security nanny
> > 
> > On Windows?
> 
> Windows, as always, is a "special" case. If a work around is
> necessary for Windows that's fine.

Err, the *only* point of this patch is Windows. The idea was to
relieve Windows users from having to hack their tar before they
can use EU::MM to bake distros that the CPAN indexer will not
reject.

If you propose a “better solution” that doesn’t work on Windows
then it might be “better” but it fails to be a “solution.”

Regards,
-- 
Aristotle Pagaltzis // 

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Aristotle Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 14:50]:
>> MakeMaker can set a minimum umask if it wants to play security
>> nanny
> 
> On Windows?

Windows, as always, is a "special" case.  If a work around is necessary for
Windows that's fine.


-- 
Hating the web since 1994.

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[David Cantrell]

On Sun, Sep 28, 2008 at 10:14:10PM +0200, Cosimo Streppone wrote:

> Could this work?

No, because --mode is a GNUism.  If you make that the default then it
will break for everyone who doesn't use GNU tar.

Having EU::MM try to use that flag when it's supported is a good idea
though.  Probably better, and easier, to just make it use Archive::Tar,
and patch that if necessary.

-- 
David Cantrell | Minister for Arbitrary Justice

Today's previously unreported paraphilia is tomorrow's Internet sensation

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Aristotle Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2008-09-29 14:50]:
> MakeMaker can set a minimum umask if it wants to play security
> nanny

On Windows?

Regards,
-- 
Aristotle Pagaltzis // 

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Michael G Schwern]

Aristotle Pagaltzis wrote:
> * Cosimo Streppone <[EMAIL PROTECTED]> [2008-09-29 02:10]:
>> but it seems that gnu tar doesn't like the following:
>>
>>   $ tar --mode=0755 cvf blah.tar somedir
>>   $ tar c --mode=0755 vf blah.tar somedir
>>
>> and will only accept:
>>
>>   $ tar cvf blah.tar --mode=0755 somedir
>>
>> Could this work?
> 
> GNU tar will, however, accept this:
> 
> tar cv --mode=0755 -f foo.tar bar/

MakeMaker can set a minimum umask if it wants to play security nanny,
side-stepping the "what flags do my programs take" game.


> Honestly, though, if you are using tar on Windows, I don’t know
> why you would want any other default. Patching EU::MM is the
> pragmatic approach, and we probably can’t avoid it, but I think
> it is the wrong place to fix this, still.

I would tend to agree.  Rather than papering over the root problem (no umask)
in each utility, I would rather people were educated to set their umask.


-- 
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists

[Aristotle Pagaltzis]

* Cosimo Streppone <[EMAIL PROTECTED]> [2008-09-29 02:10]:
> but it seems that gnu tar doesn't like the following:
>
>   $ tar --mode=0755 cvf blah.tar somedir
>   $ tar c --mode=0755 vf blah.tar somedir
>
> and will only accept:
>
>   $ tar cvf blah.tar --mode=0755 somedir
>
> Could this work?

GNU tar will, however, accept this:

tar cv --mode=0755 -f foo.tar bar/

BSD tar will also accept this placement of the `-f` flag,
according to the man page. Other tars may not, though I don’t
think that is very likely.

However, the `--mode` switch is a GNU curiosity. No other tar
that I checked does have it.

Honestly, though, if you are using tar on Windows, I don’t know
why you would want any other default. Patching EU::MM is the
pragmatic approach, and we probably can’t avoid it, but I think
it is the wrong place to fix this, still.

Regards,
-- 
Aristotle Pagaltzis //