In article <x7wuesu88v.fsf@bolo.xenadyne.com>,
Sean Burke <burke_sp31415@pacbell.net> wrote:

>give the resulting file the .tgz extension.
>
>> I get an error when I try to tar -cvzf a file, saying the z in not a valid
>> variable. Does this mean I need to install GNUgzip?
>
>It means you need to install gnu tar, or use
>the method

GNU tar does not create standard compliant TAR archives, use star instead:

ftp://ftp.berlios.de/pub/star
http://www.blastwave.org/packages.php


--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

> >give the resulting file the .tgz extension.
> >
> >> I get an error when I try to tar -cvzf a file, saying the z in not a
valid
> >> variable. Does this mean I need to install GNUgzip?
> >
> >It means you need to install gnu tar, or use
> >the method
>
> GNU tar does not create standard compliant TAR archives, use star instead:
>
> ftp://ftp.berlios.de/pub/star
> http://www.blastwave.org/packages.php

for hp-ux star binaries -
http://geocities.com/ian_springer/hp...es.html#schily (not supported
by HP!)

On Tue, 08 Jul 2003 23:27:16 +0000, Joerg Schilling wrote:

> In article <x7wuesu88v.fsf@bolo.xenadyne.com>,
> Sean Burke <burke_sp31415@pacbell.net> wrote:
>
>>give the resulting file the .tgz extension.
>>
>>> I get an error when I try to tar -cvzf a file, saying the z in not a valid
>>> variable. Does this mean I need to install GNUgzip?
>>
>>It means you need to install gnu tar, or use
>>the method
>
> GNU tar does not create standard compliant TAR archives, use star instead:

Of course, 1) No one cares it's not "std. compliant" as it's real life
compliant. 2) star has't fixed a bunch of the ways you can attack tar that
have been fixed in GNU tar for a long time. 3) star's command line is
annoyingly different.

--
James Antill -- james@and.org
Need an efficent and powerful string library for C?
http://www.and.org/vstr/

In article <pan.2003.07.12.03.08.44.944236@and.org>,
James Antill <james-netnews@and.org> wrote:

>> GNU tar does not create standard compliant TAR archives, use star instead:
>
> Of course, 1) No one cares it's not "std. compliant" as it's real life
>compliant.

Looks like you are missing the needed experience for the real life problems
with GNU tar. While many of the standard deviation in GNU tar have not been a
problem for many years, it seems that they hit people today. About a year ago,
people started to get problems with the mozilla source tar ball because it
has been created with GNU tar. It was impossible to extract this source with
Sun's tar because the tar ball created by GNU tar was not standard compliant.
Sun's tar reported a 'directory checksum error' which shows that there is a
hard deviation from the standard....

> 2) star has't fixed a bunch of the ways you can attack tar that
>have been fixed in GNU tar for a long time.

So far, nobody did report any problem you seem to refer to....

If you don't tell us what you are talking about, it is the best to just ignore
this objection from you.

Otherwise tell us what you mean: What excaptly are you talking abut and how
exactly has this been fixed in GNU tar. But keep in mind that I will not
add "fixes" that will cause bigger problems than those originally present....

There is currently not a single reported but unfixed bug in star. GNU tar did
not even fix all of the bugs I reported around 1994! As in 1998 not a single
bug reported in 1994 has been fixed in GNU tar, I gave up reporting GNU tar
bugs. There are many more than I have documented in

ftp://ftp.berlios.de/pub/star/README.otherbugs
and
ftp://ftp.berlios.de/pub/star/testsc...EADME.gtarfail

While star has a lot more features than GNU tar (once you start to use them
you would never again like to use GNU tar) I sometimes tried to implement a
feature found in GNU tar but at that time not yet in star. When I though about
problems in a possible implementation, and checked GNU tar, I always found a bug
in GNU tar.

Many of those bugs are related to the multivolume features in GNU tar. So far I
can tell, the only place where GNU tar currently has a better implementation is
when it comes to integer overflows in user/group ids. But even there you may
only rely in problem reporting from GNU tar not in a handling of the resulting
problem that is always how you would expect it to be done.

3) star's command line is
>annoyingly different.

It is just the other way round: star's command line is UNIX-98 compliant and
tries it's best to follow POSIX command line syntax guidlines.

GNU tar is _not_ providing a UNIX-98 compliant command line syntax and many other
things in the GNU tar commans line syntay are annoyingly different to all other
tar implementations including star.

In case you are a Linux follower: star is even 100% LSB compliant and may be used
without any problem in 100% LSB compliant Linux systems:

http://www.linuxbase.org/spec/refspe.../gLSB/tar.html

Conclusion: it seems that you never used star and you for unknown reason prefer
the annoyingly different command line syntax from GNU tar.

As I already wrote above: all people who started to use star in the past would
never revert to another tar implemantetion later.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

In article <AImnELE66$D$Ewtf@ponle.demon.co.uk>,
Walter Briscoe <wbriscoe@ponle.demon.co.uk> wrote:
>In message <pan.2003.07.12.03.08.44.944236@and.org> of Fri, 11 Jul 2003
>23:08:49 in comp.unix.misc, James Antill <james-netnews@and.org> writes

>>>>give the resulting file the .tgz extension.
>>>>
>>>>> I get an error when I try to tar -cvzf a file, saying the z in not a valid
>>>>> variable. Does this mean I need to install GNUgzip?
>>>>
>>>>It means you need to install gnu tar, or use
>>>>the method
>>>
>>> GNU tar does not create standard compliant TAR archives, use star instead:
>Chapter & verse? I presume "standard compliant" means compliant with
>http://www.opengroup.org/onlinepubs/...ities/pax.html

See later for the standard you mention here.....

First, there is http://www.opengroup.org/onlinepubs/...9/xcu/pax.html
which is commonly called UNIX-98. The TAR archive standard format
described in this standard is identical to POSIX.1-1990, star is the only known
TAR implementation that correectly implements this standard. GNU tar does not
even follow this standard although it's precursor (PD-tar) where GNU tar has
been derived from did implement a clean subset of the POSIX standard in 1987.
The fact that GNU tar is not POSIX compliant has been "implemented" by FSF -
most likely by Jay Fenlason (hack@ai.mit.edu).

Unfortunately, not even the officiel PAX reference implementation implements
http://www.opengroup.org/onlinepubs/...9/xcu/pax.html correctly. To learn
where exactly the deviations are, get a recent star source, e.g.

ftp://ftp.berlios.de/pub/star/alpha/star-1.5a16.tar.gz

and use the program called 'tartest' together with the related documentation.
This of course may also used to understand why GNU tar is not POSIX archive
compliant.

Now to your URL
http://www.opengroup.org/onlinepubs/...ities/pax.html

it describes a new TAR format called 'PAX' which is POSIX.1-1990 TAR + extended
TAR headers. Star is currently the only program that implements the 'PAX'
archive format from
http://www.opengroup.org/onlinepubs/...ities/pax.html


>> Of course, 1) No one cares it's not "std. compliant" as it's real life
>>compliant. 2) star has't fixed a bunch of the ways you can attack tar that
>>have been fixed in GNU tar for a long time. 3) star's command line is
>>annoyingly different.
>>
>Details?

Star implements a command line parser that is compliant to:

http://www.opengroup.org/onlinepubs/...9/xcu/tar.html

GNU tar does not.

Star in addition tries to follow
http://www.opengroup.org/onlinepubs/.../utilconv.html and
http://www.opengroup.org/onlinepubs/...bd_chap12.html
as best as possible with respect to:

http://www.opengroup.org/onlinepubs/...9/xcu/tar.html


GNU tar implemenets _and_ documents a command line syntax driven by what
getopt() supports. Note that this is _not_ what POSIX defines.
POSIX defines that the official interface is what the documentation for
the program defines - even if getopt() would allow other things in addition.
POSIX defines getopt() but does _not_ require to use it! Star uses getargs()
which is older and more powerful than getopt() and which follows the POSIX
guidelines.

A big problem with GNU tar is that its documents describe a syntax like

gtar -cbf 126 /dev/rmt/0 ....

which is definitely not compliant with any POSIX document. A program like star
that better follows POSIX requires

star -c -b 126 -f /dev/rmt/0 ...

instead.

Sometimes I get the impression that there are people besides Microsoft who
believe that it os better not to follow standards but by creating 'own
standards'.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

On Sat, 12 Jul 2003 14:42:26 +0000, Joerg Schilling wrote:

> In article <pan.2003.07.12.03.08.44.944236@and.org>,
> James Antill <james-netnews@and.org> wrote:
>
>>> GNU tar does not create standard compliant TAR archives, use star instead:
>>
>> Of course, 1) No one cares it's not "std. compliant" as it's real life
>>compliant.
>
> Looks like you are missing the needed experience for the real life problems
> with GNU tar. While many of the standard deviation in GNU tar have not been a
> problem for many years, it seems that they hit people today.

Ahh magically GNU tar is the problem without changing. Sure I can believe
there are bugs, n/p ... I've looked at the GNU tar source and it isn't
pretty. However completely changing code base isn't the solution unless
the "new" code base is obviously better (and the star source code didn't
look prettier).

>> 2) star has't fixed a bunch of the ways you can attack tar that
>>have been fixed in GNU tar for a long time.
>
> So far, nobody did report any problem you seem to refer to....
>
> If you don't tell us what you are talking about, it is the best to just ignore
> this objection from you.

Yeh, I'm sorry ... I shoudl have realized that actually looking at old
security announcments for your main competitor would be too much to ask.
Obvious security stuff...

- rmt doesn't check .. in paths
- mt assumes a 128 byte dns limit (it does cut off stuff but this
is still wrong for DNS since about 1998)
- setuid operation does not function properly when creating
archives [uses access which tests v real uid]
- doesn't work around symlink's allowing you to write anywhere
in the fs.

....and the bigger non-security...

- no internationalisation support
- help outputs invalid utf-8 in utf-8 modes
- tar -xzvf foo.tar.gz ... doesn't work.

....this is/was with version 1.4.1 IIRC.

> 3) star's command line is
>>annoyingly different.
>
> It is just the other way round: star's command line is UNIX-98 compliant and
> tries it's best to follow POSIX command line syntax guidlines.

So what, my fingers don't stop typing things just because they aren't in
UNIX-98 ... indeed my fingers have been typing tar -xzvf since _at least_
1995. And what does star display...

Usage: ./star/OBJ/athlon-linux-cc/star cmd [options] file1 ... filen

Use ./star/OBJ/athlon-linux-cc/star -help
and ./star/OBJ/athlon-linux-cc/star -xhelp
to get a list of valid cmds and options.

Use ./star/OBJ/athlon-linux-cc/star H=help
to get a list of valid archive header formats.

Use ./star/OBJ/athlon-linux-cc/star diffopts=help
to get a list of valid diff options.

....wow that just fills me with confidence.

> GNU tar is _not_ providing a UNIX-98 compliant command line syntax and many other
> things in the GNU tar commans line syntay are annoyingly different to all other
> tar implementations including star.

But the thing is almost everyone just installs gtar in /usr/local or
whatever on Solaris/AIX/etc. anyway.

--
James Antill -- james@and.org
Need an efficent and powerful string library for C?
http://www.and.org/vstr/

In article <pan.2003.07.15.00.18.29.988087@and.org>,
James Antill <james-netnews@and.org> wrote:

>>> Of course, 1) No one cares it's not "std. compliant" as it's real life
>>>compliant.
>>
>> Looks like you are missing the needed experience for the real life problems
>> with GNU tar. While many of the standard deviation in GNU tar have not been a
>> problem for many years, it seems that they hit people today.
>
> Ahh magically GNU tar is the problem without changing. Sure I can believe

GNU tar is not magically the problem but because it is non-standard.
If you refuse to live in a standard compliant world, there will be much worse
problems in your future...

>there are bugs, n/p ... I've looked at the GNU tar source and it isn't
>pretty. However completely changing code base isn't the solution unless
>the "new" code base is obviously better (and the star source code didn't
>look prettier).

The GNU tar source is close to be absolute unmaintainable. Guess why it has not
been changed significalty within the last 10 years?

I don't know wether you are able to evaluate source code. Inorder to decide
about this, I would need to see code that you have written. This is impossible,
as there is no published code from you :-( Please don't tell me that there is
www.and.org, it is not connected to the internet.

Well, star could have been better, but it is still far better code than the GNU
tar source. I was able to add POSIX.1-2001 extended TAR header handling in less
than 2 weeks, I added Solaris/BSD/Linux ACL support in less than a week and I
added BSD/Linux extended file flag support in less than 2 days. Try to do
anything similar with the GNU tar source and look at the time it takes you to
do...

In addition, it seems that are confusing which tar implementation is "new" code.
Star started in 1982 (extract only) - the first fully usable code was ready more
than 18 years ago. GNU tar started in 1989 based on John Gilmore's PD-tar which is
roughly 16 years old.

>> If you don't tell us what you are talking about, it is the best to just ignore
>> this objection from you.
>
> Yeh, I'm sorry ... I shoudl have realized that actually looking at old
>security announcments for your main competitor would be too much to ask.

???

>Obvious security stuff...
>
>- rmt doesn't check .. in paths

Looks like you never had a look at my rmt implementation.
It is the only rmt implementation that includes security checks.
It allows you to define which files may be accessed by which user
from which host.

>- mt assumes a 128 byte dns limit (it does cut off stuff but this
> is still wrong for DNS since about 1998)

Which should not be a problem for the purpose it is intended: in house
remote tape access. But if you really believe that you ned more,
you need to send a report to me - you did not do so far..


>- setuid operation does not function properly when creating
> archives [uses access which tests v real uid]

- Have you ever read the man page for access(2)?
access has been designed for checking real user id
if real/effectife uid are different because there
needs to be a way to check accessibility for the
real uid.

- Have you ever had a look into the star source?
Star only uses access(2) once for checking for
existence of a directory. This is not setuid related at all.


>- doesn't work around symlink's allowing you to write anywhere
> in the fs.

Have you ever used star?

Have you ever had a look at the way this "security risk" has been
"circumvented" in GNU tar and do you know what big problems this method
creates with newer GNU tar versions?

I already told you that I will not change my code of the new version
would obviously be creating bigger problems than the old version.

1) Star in contrary to GNU tar will not be trtiggered in most of
the possible cases

2) There are people which like to use symlinks in order to redirect
the extracted fils. GNU tar will block people from doing this
because there is no way to even swich the buggy GNU tar method off.


>...and the bigger non-security...
>
>- no internationalisation support

Not a real problem as it is far more important to have a clean set of
usable features rather than a program that will "talk french".

>- help outputs invalid utf-8 in utf-8 modes

??? You sound confused!

Iss it possible that your work environment is hosed?

>- tar -xzvf foo.tar.gz ... doesn't work.

This is 100% correct: It is a incorrect usage.

In addition, 'z' has been introduced by GNU tar, so this is non-standard
at all.

With star, you just use either the official standard method for historical
tar:
star xvf foo.tar.gz

and star will auto-detect compression.

Or you use the new POSIX method of specifying options:

star -x -v -f foo.tar.gz

Your command line example is not compliant to any of both methods.
It is just an illegal and higly risky (because it may kill file content)
mix of the official old tar interface and the new POSIX command interface.


>...this is/was with version 1.4.1 IIRC.

You seem to like using outdated versions

>> 3) star's command line is
>>>annoyingly different.
>>
>> It is just the other way round: star's command line is UNIX-98 compliant and
>> tries it's best to follow POSIX command line syntax guidlines.
>
> So what, my fingers don't stop typing things just because they aren't in
>UNIX-98 ... indeed my fingers have been typing tar -xzvf since _at least_
>1995. And what does star display...

If your fingers are typing the wrong commands, you need to educated or train them
in a correct way.


>> GNU tar is _not_ providing a UNIX-98 compliant command line syntax and many other
>> things in the GNU tar commans line syntay are annoyingly different to all other
>> tar implementations including star.
>
> But the thing is almost everyone just installs gtar in /usr/local or
>whatever on Solaris/AIX/etc. anyway.


My conclusion on your statements is:

you try to deprecate star by making unprecise and mostly wrong claims.
If I ask you to prove your claims, you do not do this but rather send new
unprecise and mostly wrong claims.
If you find problems in star, then you should send a specific bug report
that allows me to repeat the problem. I will of course fix obvious bugs.


you seem to miss the knowledge on the behaviour of a "real tar" just
because you did us GNU tar for too long time. Would you really ask me to
follow bad ideas of other people? It is much easier for you and your
future to try to understand the official old tar command line interface _and_
the new general POSIX command line interface for all commands. Once you started
to use star, you will no longer complain about it's command line interface
and believe me that the interface star implements is best compromise between
a correct "old tar" interface and a generic POSIX command interface.

Once you start to use one of the many features in star that are missing
in GNU tar, you would never like to get GNU tar back.

Just have a look at:

- The user tailorable "diff"

- The user tailorable error control that allows you to filter
out specific error conditions for specific file name patterns.

- The increased features that are possible because star implements
POSIX.1-2001 extended TAR (PAX) headers.

- Fast (streaming) tape writes because of the built in FIFO

- Fast remote tape handling (up to 4x faster than GNU tar)

- The security enhancements and crontrols in the rmt server
that comes with star (tailorable via /etc/default/rmt).

- Powerful built in pattern matcher

- Star does not clobber files on disk that are older than
the file in the archive.

- Automatic byte swap for alien architectures.

- Automatic TAR archive format detect: star/ustar/gnu-tar/sun-tar/..


- Automatic compression detect

- ACL support

- Extended file flag support

- Support for meta-data-only plain files (to avoid archiving gigabytes
of data if only e.g. a "chmod" has been made on the file).

- Support for all inode metadata and all file types allows "true
incremental backups"

- Support to compare all inode metadata in diff mode.

- The ability to extract copies instead of sym/hard-links on OS that
do not support links.


Also note that most enhanced features from GNU tar (such as e.g. -block-number)
do not work properly in GNU tar but work correctly in star.


.... Read STARvsGNUTAR and README.otherbugs for additionnal informations.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joerg Schilling wrote:
>
> - Automatic compression detect

I know it is sad to admit my brain doesn't always instruct my fingers to
insert relevant uncompress options, but this one alone could sell star
to me
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/FbCbGFXfHI9FVgYRAv3nAJ99hNoiQ3BymWy3XuiH9JtyElSH3Q CdHtMl
rK4Loj0FGB/KkrGuuN474gQ=
=F4U6
-----END PGP SIGNATURE-----

On Wed, 16 Jul 2003 15:27:05 +0000, Joerg Schilling wrote:

> In article <pan.2003.07.15.00.18.29.988087@and.org>,
> James Antill <james-netnews@and.org> wrote:
>
>> Ahh magically GNU tar is the problem without changing. Sure I can believe
>
> GNU tar is not magically the problem but because it is non-standard.

The point was that it may be non-standard, but if so then it's been that
way for a while ... it has suddenly become non-std. ... so if things have
stopped working it means that something else changed which caused the
problem. You may argue whatever changed is justified to happen, but it
isn't all GNU tar's fault.

> If you refuse to live in a standard compliant world, there will be much worse
> problems in your future...

"The wonderful thing about standards is that there are so many to choose
from"

In my world "tar -xzvf foo.tar.gz" is a std. interface. But hey I've just
seen hundreds of scripts by different people using features on my side,
you've got a piece of paper.

> I don't know wether you are able to evaluate source code. Inorder to decide
> about this, I would need to see code that you have written. This is impossible,
> as there is no published code from you :-( Please don't tell me that there is
> www.and.org, it is not connected to the internet.

The site was down for almost 2 days from the 14th.
As for star, from what I saw of it before I just gave up...

1. Way too many #ifdef's in the C files.
2. No real string type, so I have to "presume" that you are exceptionally
good enough to not have them.
3. No namespace rules.

....and yes GNU tar fails them all too, but at least everyone is using that
so it's got some chance of being ok.

> Well, star could have been better, but it is still far better code than the GNU
> tar source. I was able to add POSIX.1-2001 extended TAR header handling in less
> than 2 weeks, I added Solaris/BSD/Linux ACL support in less than a week and I
> added BSD/Linux extended file flag support in less than 2 days. Try to do
> anything similar with the GNU tar source and look at the time it takes you to
> do...

But you wrote all, or almost all, the code ... no? I'm sure if GNU tar
had it's original maintainer he would be able to add things relativley
easy.

> In addition, it seems that are confusing which tar implementation is "new" code.

I never said anything about the age of either code, IIRC. I did imply
that _many_ more people are using GNU tar than star, and if you wanted to
be taken seriously as a replacment you need a compatible command line.

>>> If you don't tell us what you are talking about, it is the best to just ignore
>>> this objection from you.
>>
>> Yeh, I'm sorry ... I should have realized that actually looking at old
>>security announcments for your main competitor would be too much to ask.
>
> ???

Well googling for "gnu tar security" gives you a different bug (which
star is also vunerable too *sigh*). Hey at least you've stopped the
obvious absolute path names.
However the symlink one did go up on bugtraq etc.

>>Obvious security stuff...
>>
>>- rmt doesn't check .. in paths
>
> Looks like you never had a look at my rmt implementation.

Gee you're right I must have just made it up when I looked in rmt/rmt.c
opentape() and saw...

if (!checktape(device)) {
tape_fd = -1;
seterrno(EACCES);
} else {
tape_fd = open(device, omodes, 0666);
}

....then looked in checktape() and saw...

if (!found_dfltfile) {
if (strncmp(device, "/dev/", 5) == 0)
return (1);
return (0);
}

....and though "/dev/../etc/passwd" ... yes
I think you can work around it by setting up an access control file.

>>- doesn't work around symlink's allowing you to write anywhere
>> in the fs.
>
> Have you ever used star?

Have I created bad tar files, and seen that star ignorantly just creates
files anywhere ... sure.

> Have you ever had a look at the way this "security risk" has been
> "circumvented" in GNU tar and do you know what big problems this method
> creates with newer GNU tar versions?

Yes, and no.

> I already told you that I will not change my code of the new version
> would obviously be creating bigger problems than the old version.
>
> 1) Star in contrary to GNU tar will not be trtiggered in most of
> the possible cases

I have no idea what you are saying here "star xvf foo.tar" will write
files anywhere you have write access to, via. at least two security holes.

> 2) There are people which like to use symlinks in order to redirect
> the extracted fils. GNU tar will block people from doing this
> because there is no way to even swich the buggy GNU tar method off.

This is about symlinks that then have data on the other side of them, _in
the same tarfile_ though ... it's not possible to create them that way
AFAIK, so I fail to see how it can be a good idea to extract them that
way.
Sure I guess you can argue that it's a feature, just like a buffer
overflow "allows" you to do things that not having the buffer overflow
doesn't ... but so what.

>>- help outputs invalid utf-8 in utf-8 modes
>
> ??? You sound confused!
>
> Iss it possible that your work environment is hosed?

This was probably just fallout from the fact that you don't care about
i18n.

>>- tar -xzvf foo.tar.gz ... doesn't work.
>
> This is 100% correct: It is a incorrect usage.

This is 100% in scripts: It needs to work.

> In addition, 'z' has been introduced by GNU tar

Sure, at least 8 years ago. Which makes it pretty std.

> With star, you just use either the official standard method for historical
> tar:
> star xvf foo.tar.gz
>
> and star will auto-detect compression.
>
> Or you use the new POSIX method of specifying options:
>
> star -x -v -f foo.tar.gz
>
> Your command line example is not compliant to any of both methods.
> It is just an illegal and higly risky (because it may kill file content)
> mix of the official old tar interface and the new POSIX command interface.

I'm not sure which world you live in, but in mine all sane programs allow
you to drop the " -" between each option. And I fail to see how it could
possible "kill file content"

>>...this is/was with version 1.4.1 IIRC.
>
> You seem to like using outdated versions

So all those bugs are fixed in the new version, then?

> If your fingers are typing the wrong commands, you need to educated or train them
> in a correct way.

Sure ... I'll do that right after I turn into a fairy and fix almost
everyone's scripts.

> you try to deprecate star by making unprecise and mostly wrong claims.

I said it the UI was incompatible with real life, and it is ... and I
said it had years old security holes in it, and it does.

> If I ask you to prove your claims, you do not do this but rather send new
> unprecise and mostly wrong claims.

> you seem to miss the knowledge on the behaviour of a "real tar" just
> because you did us GNU tar for too long time. Would you really ask me to
> follow bad ideas of other people? It is much easier for you and your

Why is it bad for tar to act like every other Linux command, and my Linux
machine?

> future to try to understand the official old tar command line interface _and_
> the new general POSIX command line interface for all commands. Once you started
> to use star, you will no longer complain about it's command line interface
> and believe me that the interface star implements is best compromise between
> a correct "old tar" interface and a generic POSIX command interface.

I think not.
Pretty much the only[1] thing I use GNU tar for is...

tar -xzvf foo.tar.bz2
tar -xzvf foo.tar.gz
tar -cvf foo.tar <whatever>

....and star doesn't work in any of the three cases.

[1] Yes, I do have a patch for GNU tar to auto detect the gz/bz2 thing so
the above is right.

--
James Antill -- james@and.org
Need an efficent and powerful string library for C?
http://www.and.org/vstr/

In article <pan.2003.07.17.06.00.59.628181@and.org>,
James Antill <james-netnews@and.org> wrote:

Sorry for being long but I don't like to make unspecific and thus not
verifiable statements like you.

>> GNU tar is not magically the problem but because it is non-standard.
>
> The point was that it may be non-standard, but if so then it's been that
>way for a while ... it has suddenly become non-std. ... so if things have

WRONG: I am not sure if you simply don't like to understand this but GNU tar
has been non-standard since around 1990. The PD-tar from John Gilmore has been
standard compliant (but did only implement a subset of the standard).
When FSF people started to work on PD-tar to make it GNU-tar, they modified it
in a way that caused the non-standard behavior.


>stopped working it means that something else changed which caused the
>problem. You may argue whatever changed is justified to happen, but it
>isn't all GNU tar's fault.

??? I mentioned before that the non-standard behavior of GNU tar was not a big
problem in former days because PATH names have been short enough so no actual
problem has been triggered by the non-compliance. These days, PATH names did
become longer and now the way GNU tar archives PATH names > 100 chars has become
a visible problem.

>"The wonderful thing about standards is that there are so many to choose
>from"

So you believe that you are like Bill Gates and just define your own standards?
For a computer environment, there is an accepted standard called POSIX.
A first version has been accepted in 1988 and 1990. As this old standard did not
contain enough rules for a usable computing platform, OpenGroup created the
so called SUS (Single UNIX specification - otherwise known as UNIX-95) and SUS-v2
(otherwise known as UNIX-98) which most UNIX like systems currently conform to.
Even Linux is currently on a way to conform to UNIX-98.


> In my world "tar -xzvf foo.tar.gz" is a std. interface. But hey I've just
>seen hundreds of scripts by different people using features on my side,
>you've got a piece of paper.

Sorry, but you need to learn that this is wrong: Even your preferred OS (Linux)
and maybe the only system where your sources compile,
does not officially allow this command line, see:

http://www.linuxbase.org/spec/gLSB/gLSB/tar.html

Describes the official behavior of the "tar" command on Linux.
Star is 100% compliant to this definition - so if the rest of your
Linux system is 100% LSB compliant, you will not see any problem.

Conclusion: you did see hundreds of broken scripts that need to be fixed.

>> I don't know wether you are able to evaluate source code. Inorder to decide
>> about this, I would need to see code that you have written. This is impossible,
>> as there is no published code from you :-( Please don't tell me that there is
>> www.and.org, it is not connected to the internet.
>
> The site was down for almost 2 days from the 14th.

It was not reachable at for at least 4 days.

OK, I now have been able to check your code and I am sorry, but it is far
worse than mine:

- It uses a non standard compliant archive format in vstr-1.0.6.tar.gz

- The autoconf code looks rotten: it takes 14 Minutes on a Sun-3/60
before the first line is printed and it takes 2:10 (130 minutes)
to complete on the same machine. In this time I would have compiled
many megabytes of souces on the same machine.

- The makefiles created are not standard compliant so in contrary
to the statements in the file "INSTALL" which clames
2. Type `make' to compile the package.
It does not work to type "make". Note that I did test this on
many platforms.....
Only "gmake" is able to work with your nonstandard make files.

For more information look at line 117 in e.g. file vstr-1.0.6/Makefile

- I tried to compile it on many platforms with very disaterous results.

- HP-UX 10.x & 11.x no compilation at all - neither with cc nor
with gcc

- SunOS-4.1 No compilation at all - neither with cc nor with gcc

- SCO UnixWare-7.1.3 cc:

UX:acomp: WARNING: "../include/main_system.h", line 111: invalid directive
UX:acomp: WARNING: "../include/main_system.h", line 114: invalid directive
UX:acomp: WARNING: "../include/fix.h", line 209: invalid directive
UX:acomp: WARNING: "../include/fix.h", line 214: invalid directive
UX:acomp: ERROR: "../include/vstr-extern.h", line 717: syntax error, probably missing ",", ";" or "="

- SCO UnixWare-7.1.3 gcc:
../include/vstr-extern.h:717: parse error before `vstr_parse_intmax'
../include/vstr-extern.h:720: warning: data definition has no type or storage class

- Solaris 9 cc:

cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -g -c vstr_add_fmt.c -KPIC -DPIC -o vstr_add_fmt.o
"vstr_add_fmt.c", line 1317: warning: argument #4 is incompatible with prototype:
prototype: pointer to int : "vstr_add_fmt.c", line 443
argument : pointer to unsigned int
..... actually many more.
repeated many times.
Note that it is bad coding style to write in a way that you
get warnings even with warnings turned off....

cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -g -c vstr_conv.c -KPIC -DPIC -o vstr_conv.o
"vstr_conv.c", line 328: warning: initializer does not fit or is out of range: 128
... actually many more
see above.

cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -g -c vstr_parse.c -KPIC -DPIC -o vstr_parse.o
"vstr_parse.c", line 332: warning: end-of-loop code not reached
... actually many more
see above

/usr/ccs/bin/ld -G -h libvstr-1.0.so.0 -o .libs/libvstr-1.0.so.0.0.6 assert_loop.lo fix.lo vstr.lo vstr_add.lo vstr_add_fmt.lo vstr_add_netstr.lo vstr_cache.lo vstr_cmp.lo vstr_cntl.lo vstr_conv.lo vstr_cstr.lo vstr_del.lo vstr_dup.lo vstr_export.lo vstr_fmt.lo vstr_inline.lo vstr_mov.lo vstr_parse.lo vstr_parse_netstr.lo vstr_ref.lo vstr_sc.lo vstr_sc_posix.lo vstr_sect.lo vstr_spn.lo vstr_split.lo vstr_srch.lo vstr_srch_case.lo vstr_sub.lo vstr_version.lo -lnsl -lc -e vstr_version_func
ld: Schwerer Fehler: Symbol `vstr__base_scan_rev_nxt' ist mehrfach definiert:
(Datei assert_loop.lo und Datei fix.lo);
ld: Schwerer Fehler: Symbol `vstr__base_scan_rev_beg' ist mehrfach definiert:
(Datei assert_loop.lo und Datei fix.lo);

.... hundreds of simular messages as a result of noncompliant
coding (putting global funtion implementations into *.h files).

Let me give up here! Star and all my programs (actually 30 MB of source code)
compile on more than 30 different platforms witout manual intervention.
Before you like to discuss code quality and coding style with me, it would help
if you try to make your software portable and following the official C-syntax.

It could also help a lot for readability of your sources, if you would try to
follow the usual indentation style. I send you an example of "cstyle" output
in a private mail. Interesting is that you have many lines that end with
white space...

You might want to use google to look for "cstyle tar" to get information
on good coding style.

> As for star, from what I saw of it before I just gave up...
>
>1. Way too many #ifdef's in the C files.

You have even more of them for your code that is easier to make portable,
so what is your problem?

>2. No real string type, so I have to "presume" that you are exceptionally
> good enough to not have them.
>3. No namespace rules.

Let us discuss things like this after _your_ code compiles on at least 5 different
platforms without manual intervention OK?

>...and yes GNU tar fails them all too, but at least everyone is using that
>so it's got some chance of being ok.

So you are from the fraction: "eat shit, millions of flies cannot be wrong"?

>> In addition, it seems that are confusing which tar implementation is "new" code.
>
> I never said anything about the age of either code, IIRC. I did imply
>that _many_ more people are using GNU tar than star, and if you wanted to
>be taken seriously as a replacment you need a compatible command line.

And there are more and more people using star just because it is e.g. the only
way to make a backup of a filesystem with ACLs on Linux.


> Well googling for "gnu tar security" gives you a different bug (which
>star is also vunerable too *sigh*). Hey at least you've stopped the
>obvious absolute path names.

You look a bit childish... sorry, but this has been introduced 10 years ago;
most likely even before GNU tar intruduced a similar fix....


> However the symlink one did go up on bugtraq etc.

Bugtraq for star? Try to be a bit more precise. This would make it much easier
to have a discussion with you.

>>>- rmt doesn't check .. in paths
>>
>> Looks like you never had a look at my rmt implementation.

>...and though "/dev/../etc/passwd" ... yes
>I think you can work around it by setting up an access control file.

AHA, now you are using no more a lazy writing style and make your text
readable.... Well, this could be fixed easily. Why didn't you make a bug report?

>>>- doesn't work around symlink's allowing you to write anywhere
>>> in the fs.

>> Have you ever used star?
>
> Have I created bad tar files, and seen that star ignorantly just creates
>files anywhere ... sure.

You did not! See below....

If you really find new problems, you should _document_ them and write a
bug report.

Telling people nothing but: "There is some bugs" is bad style.

>> Have you ever had a look at the way this "security risk" has been
>> "circumvented" in GNU tar and do you know what big problems this method
>> creates with newer GNU tar versions?
>
> Yes, and no.
>
>> I already told you that I will not change my code of the new version
>> would obviously be creating bigger problems than the old version.
>>
>> 1) Star in contrary to GNU tar will not be trtiggered in most of
>> the possible cases
>
> I have no idea what you are saying here "star xvf foo.tar" will write
>files anywhere you have write access to, via. at least two security holes.

You just prooved that all your claims are claims made from expectations but
not from real life tests:

star tv < x
star: Blocksize = 5 records.
0 lrwxrwxrwx jes/berlios Jul 17 14:55 2003 from -> to
9 -rw-r--r-- jes/berlios Jul 17 14:55 2003 from
star: 1 blocks + 0 bytes (total of 2560 bytes = 2.50k).

star xv < x
star: Blocksize = 5 records.
x from symbolic link to to
star: current 'from' newer.
star: 1 blocks + 0 bytes (total of 2560 bytes = 2.50k).

ls -l from to
to: Datei oder Verzeichnis nicht gefunden
lrwxrwxrwx 1 jes berlios 2 Jul 17 14:56 from -> to


>>>- help outputs invalid utf-8 in utf-8 modes
>>
>> ??? You sound confused!
>>
>> Iss it possible that your work environment is hosed?
>
> This was probably just fallout from the fact that you don't care about
>i18n.

So you just admit that your environment is hosed as you seem to be unable to
even explain your problems :-(


>> With star, you just use either the official standard method for historical
>> tar:
>> star xvf foo.tar.gz
>>
>> and star will auto-detect compression.
>>
>> Or you use the new POSIX method of specifying options:
>>
>> star -x -v -f foo.tar.gz
>>
>> Your command line example is not compliant to any of both methods.
>> It is just an illegal and higly risky (because it may kill file content)
>> mix of the official old tar interface and the new POSIX command interface.
>
> I'm not sure which world you live in, but in mine all sane programs allow
>you to drop the " -" between each option. And I fail to see how it could
>possible "kill file content"

You seem to live in a different world than most people here in c.u.s.

I have seen many .c files haveing been converted into tar archives because
somebody just did call something like:

tar cbf 1 *.c

instead of

tar cbf 126 1 *.c

This is why old versions of star did not allow the historic tar syntax at all.
I few years ago, I decided to allow (with some security exceptions) what
UNIX-98 defines.

as it seems that you are a newcomer and miss the historic knowledge:

'tar' and 'ar' are commands with similar exceptions. Calling "ar -tv archive"
will on many systems result in an error message:

ar: bad option `-'

And in case you don't know it: POSIX allows single char boolean options
to be combined, but this is not true for options that need parameters.

tar -tvf file

therefore definitely is illegal in the old historic tar world _and_ in
the current POSIX world. Only the fact that you cannot really forbid illegal
things, may be the reason that it works to call above command line on _some_
systems. But if you would be a careful person you should never rely on it.


> Why is it bad for tar to act like every other Linux command, and my Linux
>machine?

Whell this is exactly what star is doing: it follows the general POSIX command
line syntax rules and offers an exception for the old historic tar syntax.


> Pretty much the only[1] thing I use GNU tar for is...
>
>tar -xzvf foo.tar.bz2
>tar -xzvf foo.tar.gz
>tar -cvf foo.tar <whatever>
>
>...and star doesn't work in any of the three cases.

Because all these cases are illegal and thus not granted to work on a specific
platform.

If you did write shell scripts that contain any of them you should fix them.
If you find other peoples scripts, you should send them a note.

There are already people who did replace GNU tar with star on their Linux
system and the only problem reported was that the GCC source uses an incorrect
tar syntax for about 5% of all tar calls. Note that the authots obviously did
know about what is correct otherwise less than 95% of all calls would have
been correct.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily