So, I think I finally get it. Joerg's argument really has to do with a -/ option in cpio/pax/tar as they exist in Solaris today would cause them to be incompatible with star and its ability to be implemented as tar/pax/cpio as a link of some sort. I couldn't figure out why it was a big deal that different commands that do similar things have similar options that do different things. While it is optimal to prevent this sort of thing, it is not a hard requirement, unless you desire to use the same binary to replace the existing three distinct commands.
Joerg objection seems to be that since he would like to see star replace the current Solaris cpio/pax/tar commands with a link to star, then adding an conflicting option to cpio/pax/tar as proposed in the FastTrack is an impediment to that ever happening. Is there any proposal in front of any ARC (or approved by any ARC) to replace these Solaris commands with links to star? -- Joerg Schilling wrote: > James Carlson <james.d.carlson at Sun.COM> wrote: > > >>Joerg Schilling writes: >> >>>If interface stability is really important for OpenSolaris, then tar(1), >>>cpio(1) and pax(1) cannot implement an incomatible way of handling the -/ >>>option. The option -/ (introduced in 1994) has the following meaning: >> >>This is the point where there's a problem. > > > The problem is that someone at Sun likes to introduce incompatible bahavor > like "... resistance is futile". > > Solaris needs and adopts OpenSource software from free sources outside of Sun. > People inside Sun are interested that these OSS programs fit nicely into > OpenSolaris. This looks like OpenSolaris is "interested" on OSS applications > that care about the needs of OpenSolaris. > > Wouldn't it be nice if there is a guesture from people inside Sun like: > "We care about your needs and hope that you care about our needs"? > > Synergy only happens if both parties benefit.... > > > >>Your version of tar has no more to do with /usr/bin/tar on OpenSolaris >>than does GNU tar, AIX tar, or any other implementation. > > > Sorry, but you seem to be uninformed abut reality! > > Star has been first written on UNOS in 1992. It has been ported to SunOS > in spring 1985. There always was the will to be compatible with /usr/bin/tar > on SunOS as far as possible. Sun started to become incompatible in the mid > 1990s. > > Then several years ago, a discussion about a better /etc/rmt from the star > package and later one about replacing /usr/bin/tar by star was under way with > Dworkin Muller. As star is written in a way that makes it highly configurable > and as a result of this discussion, the following programs have been created > and added in summer 1993 to the star packet: > > - suntar.c A program intended to be 100% compatible to Sun tar and to > replace /usr/bin/tar > > - cpio.c A program intended to be 100% compatible to Sun cpio and to > replace /usr/bin/cpio > > - pax.c A program intended to be 100% compatible to POSIX / Sun pax and > to replace /usr/bin/pax > > As star (in contrary to /usr/bin/tar) takes care about security/vulnerability > issues that are a result of hand crafted tricks in archives or a result of > side effects in archives created by careless users, star by default rejects > to > unpack files in archives that may result in a compromised system. The files > in question that are a security risk and that are blocked by star in extract > mode are symlinks and hardlinks that include "/../" in the target path (these > files are not extracted) and files with a name that begins with "/" (these > files are extracted with the leading "/" striped off. Star also detects > and blocks files that are hardlinks to itself and that allow usual tar > implementations to be abused to remove files without the caller noticing the > problem. > > This behavior of star is not forbiden by POSIX and gives a significant > security > improvement. > > As I do not like to create insecure replacements for /usr/bin/tar, > /usar/bin/cpio and /usr/bin/pax, the security precautions from the basic > algorithm in star is not disabled by default. Instead, the programs listed > above > implement additional options -/ and -.. as star does. This was not a problem > in > 2003 and it was not a problem on June 16th 2004 when PSARC 2004/480 was > approved on a PSARC meeting. At the time when the case was approved, the > manual > pages have been part of the case to the options -/ and -.. have been approved > too. > > After the PSARC case was approved, Dworkin Muller left Sun. This is usually > not > a problem in a big company like Sun... > > Now it seems that it was a problem with Sun. THe case was left alone and the > integration (definitely planned to take place before Solaris 10 GA) did not > happen. > > The programs tar/cpio/pax have been created to be as compatible as possible to > the Sun programs. > > Now in 2007, it looks to me as if the work that has been done in good faith > is not only ignored but worked against. > > If we do not prevent the introduction of incompatible options into > tar/cpio/pax, > the plan to give Solaris modern, safe and feature rich replacements for the > dusty old implementations will be made impossible just by this planned act. > > > >>Yes, it'd be possible _in the future_ to create a project that removes >>the OpenSolaris tar sources (and pax and cpio) and replaces them with >>links to star. Yes, it might even be helpful to do so. >> >>However, that project doesn't currently exist. There is no ARC case >>that specifies it. There's no plan showing when (or if) it will ever >>show up. All that we have is a hint in 2004/480 that this "might" be >>a future project. > > > See above and understand what really happened... > > >>You're thus asking that we block an otherwise reasonable project on >>the grounds that maybe -- someday -- there might be a conflict with >>some other implementation. How far does that extend? How many other >>people have created their own personal variants of common tools? >>Should we survey them all, or do just yours alone matter? > > > Sorry, I am just requesting to prevent to implement enhancements in an > _unrasonable_ way. I am not trying to prevent feature enhancements. > This ARC case however tries to prevent future feature enhancements. > > J?rg > -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 ---------------------------------------------------------------------
