Re: Security risk in uudecode specification?
On 1/14/23 10:49, Robert Elz wrote: Yes, it can, but the assumption in all of this is that somehow root is being convinced to run the extraction without applying any thought to it (without that, uuencode is no more dangerous than cp). If we're assuming that root can be fooled that way, we may as well assume that root could as easily be convinced that the -P option should be given (tell root that that option preserves the modify times, or something) or perhaps get root to run tar with -C / ... either way would have the same effect. I've never seen it in use, but I've seen references to some sendmail configurations having a "decode" alias that automatically uudecoded files without human review, which would fit that assumption: https://exchange.xforce.ibmcloud.com/vulnerabilities/126 http://www.linuxmisc.com/14-unix-administering/043656233142e746.htm https://www.stigviewer.com/stig/solaris_10_x86/2020-12-04/finding/V-220104 (Though I'd argue having such an automated method is the vulnerability there, not the underlying tool being used.) | At the very least here, I thought the standard committee would want to | consider that all of the major implementations of uudecode follow a | defacto standard on removing bits from the permissions that doesn't | seem to be allowed by the current language of the formal standard. Yes, that is an issue that probably should be considered, as what the standard describes doesn't match what implementations actually do. But that won't happen until some submits a bug report in the proper form (ideally complete with new text to update things). I started down that path, but am unclear on some details of the wording used in the standard. Right now, on https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html it says: "The mode bits of the created file (other than standard output) shall be set from the file access permission bits contained in the data; that is, other attributes of the mode, including the file mode creation mask (see umask), shall not affect the file being produced." The definition of "File Access Permissions" at https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_05 doesn't explicitly say if that includes the setid/sticky bits or only the user/group/other bits. The definition of mode_t in the description of definitely includes the setid & sticky bits as part of the "file mode bits". So one reading of the current text is that the standard requires stripping the setid & sticky bits already, because they are not part of the permission bits, and only permission bits may be set in the mode, but it does so in language that isn't the clearest. If that's the case, the implementations differ only in that some also clear the executable bits of the permissions - specifically those that inherited this BSD change from 1989: https://github.com/robohack/ucb-csrg-bsd/commit/ad0ffb1508477e3c540c0a64fa5b1efe86c1fbfa But the table in the Extended Description section of https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html lists the setid & sticky bit under the description "For each bit set in the octal number, the corresponding file permission bit shown in the following table shall be set" so it's not consistent that those bits are excluded from the "file permission bits". Is there a definition I've missed that makes this clear? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: Security risk in uudecode specification?
On 1/11/23 22:44, Robert Elz wrote: But ask yourself, what if the utility in question here was tar, or pax, or cpio (or whatever it is that Solaris uses for system installs and updates)? Is there any material difference to uuencode in how they operate, or what they can do (except that tar (etc) will usually set the setuid bit in extracted files if the archive says to do that - how else would "su" ever get installed correctly?) We can't compare the command specifications in the standard for tar, as there are none, but if we look at common implementations, they do in fact protect against issues such as those raised here with the paths: https://www.gnu.org/software/tar/manual/html_node/absolute.html "By default, GNU tar drops a leading ‘/’ on input or output, and complains about file names containing a ‘..’ component. There is an option that turns off this behavior" https://www.freebsd.org/cgi/man.cgi?query=tar=FreeBSD+13.1-RELEASE+and+Ports https://man.netbsd.org/tar.1 " -P, --absolute-paths Preserve pathnames. By default, absolute pathnames (those that begin with a / character) have the leading slash removed both when creating archives and extracting from them. Also, tar will refuse to extract archive entries whose pathnames contain .. or whose target directory would be altered by a symlink. This op- tion suppresses these behaviors." https://man.openbsd.org/tar.1 "-P Do not strip leading slashes (‘/’) from pathnames. The default is to strip leading slashes." https://docs.oracle.com/cd/E88353_01/html/E37839/tar-1.html "P For archive creation, suppress the addition of a trailing / on directory entries in the archive. For archive extraction, preserve pathnames. By default, absolute pathnames (those that begin with a / character) have the leading slash removed when extracting archives. Also, tar refuses to extract archive entries whose pathnames contain a dot-dot (..). This option suppresses these behaviors." At the very least here, I thought the standard committee would want to consider that all of the major implementations of uudecode follow a defacto standard on removing bits from the permissions that doesn't seem to be allowed by the current language of the formal standard. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: Security risk in uudecode specification?
On 1/11/23 14:32, Christoph Anton Mitterer wrote: The best way is to simply use -o and by that ignore the path in the file I suppose I can document that in our man page, that users should either manually verify the path in the file or manually specify an output path with -o. I do note we already deviate from a strict reading of the standard for another security issue - whatever mode is specified in the uudecode file, we mask against 0777 to strip off setuid, setgid, or sticky bits, due to a fix decades ago that our history says was brought into SunOS from the 4.3 Tahoe release of BSD to protect against auto-uudecoding by root when processing mail that came in over UUCP links long long ago. I see the FreeBSD, OpenBSD, NetBSD & GNU man pages explicitly call out "setuid and execute bits are not retained" where ours says "except setuid, setgid, and sticky-bits". The BSDs source code masks against 0666, while GNU masks against (S_IRWXU | S_IRWXG | S_IRWXO), so it appears we all agree on the setgid & sticky bits as well, they just don't call those out in the documentation. (I wonder if any implementation truly honors the standard requirement to set the mode bits exactly as specified in the file.) And of course, using -o avoids any issues with the permission bits as well. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Security risk in uudecode specification?
Below is a message sent to the Open Source Security mailing list over
the holidays about a security risk in uudecode, which the GNU maintainer
pointed out was forced by the current language of the standard.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html
indeed does seem to state that "If the pathname of the file resolves to an
existing file and the user has write permission on that file, the existing
file shall be overwritten" - regardless of file path.
Should the standard be updated here, or is it just expected that anyone
who runs uudecode has first looked at the encoded file to see what path
is specified and verified it looks safe?
Would prompting for confirmation before overwriting a file be standard
compliant, or would it require adding an option like "-i" that clearly
takes you outside of standard coverage?
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Forwarded Message
Subject: [oss-security] Directory traversal in sharutils/uudecode and python uu
module
Date: Wed, 21 Dec 2022 19:42:03 +0100
From: Hanno Böck
Reply-To: oss-secur...@lists.openwall.com
To: oss-secur...@lists.openwall.com
Hi
uuencode is an old method to encode binary data in ascii.
uuencoded files start with a line of this type:
begin 644 [filename]
If the implementation does not check for it this allows a directory
traversal attack, e.g. like this:
begin 644 /etc/shadow
Or
begin 644 ../../../../../etc/shadow
If one can convince someone with root privileges to decode such a file
this may thus compromise a system.
I discovered two implementations vulnerable to this: The uudecode tool
shipped with GNU sharutils and the uu module in python (only if no
explicit filename is given). Both are vulnerable to both variations.
I reported both on November 27th. The python security team asked me to
report it to their public bug tracker, as they don't consider it a high
risk issue:
https://github.com/python/cpython/issues/99889
The python uu module is deprecated and will be removed in python 3.13.
The python developers pointed out that it is rarely used, and it is not
vulnerable if an output file name is given.
The python binascii module contains an uu decoder that is unaffected
(as it does not directly write a file, it decodes to a variable) and no
deprecation or removal is planned. I guess this means if you're using
the python uu module you should probably switch to binascii.
I got a reply confirming the report from the sharutils developers,
pointing out that this can be interpreted as expected behavior
according to the posix standard. I don't expect a fix any time soon,
their latest release is from 2015.
--
Hanno Böck
https://hboeck.de/
Re: Anyone know how XCU/fuser got into POSIX, or why?
On 10/29/21 6:09 PM, enh via austin-group-l at The Open Group wrote: On Fri, Oct 29, 2021 at 5:45 PM Robert Elz wrote: | it's definitely unfortunate that the -k option is not part of POSIX Sorry, no idea what that is, all I know of fuser is what POSIX says about it. -k automates the 80% use case of fuser --- "kill the things using this file^Wmount point". (the other 20% being "output diagnostics for some human to look at later".) Looking at what I can see in SVR3, it appears "fuser -k" was used in the RFS scripts to kill processes using a remote file system when the server was going down. But I can't imagine why fuser would do the output interleaving if it wasn't intended for use as "kill `fuser /mnt`", so I wonder if -k wasn't in the original versions. The source even has a comment about the output being intended to be fed to kill: https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/fuser.c https://www.tuhs.org/cgi-bin/utree.pl?file=SunOS-4.1.4/usr.etc/rfs/fuser/fuser.c In SVR4, fuser -k was also used in the umountall script, if the -k option was passed to umountall. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Anyone know how XCU/fuser got into POSIX, or why?
On 10/29/21 5:45 PM, Robert Elz via austin-group-l at The Open Group wrote:
That spec requires stdout to be just an unseparated list of pids,
no white space, no terminating newline, just digits.
The SVR4 implementation (inherited by Solaris & illumos) writes white
space before each pid to stdout:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/fuser/fuser.c#L207
It seems to be an oversight in the standard that this isn't explicit.
The Solaris man page states:
The process IDs are printed as a single line on the standard output,
separated by spaces. All other output, including the single terminating
newline, is written on standard error.
And it appears the SVR3 man page (earliest I have on hand) was very similar:
The process IDs are printed as a single line on the standard output,
separated by spaces and terminated with a single new line. All other
output is written on standard error.
Do the implementations really do all the fflush() calls needed to get
the output sequenced correctly, or perhaps simply set unbuffered mode
on both stdout and stderr, and write a char at a time ?
SVR4 does fflush after writing each pid to stdout, and seems to rely
on the fact stderr is unbuffered by default:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/fuser/fuser.c#L208
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: printf (the utility) expected range of integer values
On 10/24/20 11:05 AM, Robert Elz via austin-group-l at The Open Group wrote:
It might be useful to know what the printf utility (the one
from the filesystem) outputs for
/path/to/printf '%d\n' 0xc000
on Solaris, AIX, HPUX, Linux, MacOS, and anything else
similar anyone can test that on. If you get
18446673704965373952
and no error message, then please try with more 0's appended
to actually force overflow to happen.
On Solaris 11.4:
% /usr/bin/printf '%d\n' 0xc000
printf: 0xc000: Result too large
-1
% /usr/gnu/bin/printf '%d\n' 0xc000
printf: ‘0xc000’: Result too large
9223372036854775807
(Same results on both SPARC & x86. 64-bit binaries on both.)
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.
On 9/8/20 11:45 AM, Robert Elz wrote: I knew it was from the distant past. That it was AT corporate (the commercial computer people there, back then) that made a dumb decision is no surprise, they made so many... "It came from New Jersey" was always a common explanation for why certain things had happened in Solaris engineering. This one actually, if confined to its original uses, and not proposed as a general purpose interface, is understandable. It makes no sense to require handing of "exit" in a general purpose signal name/number conversion routine however. They used it in the implementation of the killall command (to translate the signal argument) and of the /bin/sh shell (for the kill builtin, So, what happens if you use one of those commands and specify "exit" as the signal to send? Does something special case that and disallow it, or does it really do the same as "kill -s 0 ..." ? truss of "killall EXIT" and the Bourne shell builtin "kill -EXIT" does indeed show it making kill(pid, 0) calls to the processes - there's no check in the source for this, as you can see in the illumos sources: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/killall/killall.c https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/sh/jobs.c I knew kill would use these functions, killall is the kind of interface that I consider a clone (also pkill, etc). All of those could make use of a function like this - yet other systems somehow implemented those commands without it, for decades... But presumably had more places to update signal name strings when defining new signals (not that it happens very often - we last did it a decade ago, when we expanded from 8 to 32 realtime signals to match Linux). -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.
On 9/8/20 10:40 AM, Robert Elz via austin-group-l at The Open Group wrote: Date:Tue, 8 Sep 2020 17:11:16 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20200908161116.GA1829@localhost> | Initially I had assumed (from the Solaris man page) that sig2str() | only translated signal numbers, and specified it as returning -1 for | this case. Then I decided I should check whether that's right, and | discovered that Solaris translates 0 to "EXIT". That's fine. Stupid of them, but OK. According to our code history, that's the way it came from AT in 1988. It looks like they added it in SVR4.0 - I don't see it in the SVR3 sources we have archived. They used it in the implementation of the killall command (to translate the signal argument) and of the /bin/sh shell (for the kill builtin, and as guessed, for trap). -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: LC_CTYPE=UTF-8
On 6/25/20 8:31 AM, Ingo Schwarze wrote: Whether to standardize only C.UTF-8 or both C.UTF-8 and POSIX.UTF-8 as synonyms looks a bit like asking for the best colour of a bikeshed. Given that the standard already contains the redundancy of requiring both "C" and "POSIX", maybe it is more consistent to also require both "C.UTF-8" and "POSIX.UTF-8", but i don't think that matters greatly. The only thought I had along those lines was that I thought the "C" locale came from the C standard, and might be best left to the C committee to standardize, while this group controls the "POSIX" locale definition. I suspect those following the POSIX standards would end up implementing both, regardless of which specification defines each. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: LC_CTYPE=UTF-8
On 6/25/20 6:33 AM, Hans Åberg wrote: Perhaps there should be a default UTF-8 locale: It seems that the current construct does not apply so well to it. If the goal is to standardize existing behavior the standard could define the C.UTF-8 locale (or perhaps a POSIX.UTF-8 locale) that a number of systems already have, which is the standard C/POSIX locale with just the character set changed to UTF-8 instead. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Is ksh93's default alias command='command ' POSIX compliant?
On 6/15/20 11:14 PM, Stephane Chazelas wrote: 2020-06-14 16:00:58 +0200, Martijn Dekker: I am now the maintainer of what is currently, to the best of my knowledge, the only actively developed fork of AT ksh93. It is based on the last stable AST version, 93u+ 2012-08-01. Along with a few others I have been fixing a bunch of bugs. See https://github.com/ksh93/ksh for the current activity and some history/rationale in the README.md. Thanks for that. What about Oracle? Are they not maintaining a version of ksh93 for Solaris /bin/sh? We are maintaining ksh93 packages, but not doing active development work on them. Our packages are still based on the last stable release from AT - 2012-08-01 with an unfortunately high number of local patches applied: https://github.com/oracle/solaris-userland/tree/master/components/ksh93 We really don't want our ksh93 to be a separate fork, but got stuck here due to past decisions it's a bit too late to undo now. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Austin Group Frequently Asked Questions periodic update.
On 6/9/20 4:00 AM, Andrew Josey wrote: POSIX® 1003.1 Frequently Asked Questions (FAQ Version 1.17) http://www.opengroup.org/austin/papers/posix_faq.htm There's some dead links in there: Q0: http://www.pasc.org/standing/sd11.html Q4: http://www.unix-systems.org/version4/ Q12: http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=9045 http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=9634 Q13: http://www.unix.org/version4 (Looks like the domain expired, someone else bought it, and is offering it for sale at http://www.unix.org/ now.) Q16: http://www.opengroup.org/press/03nov03.htm http://www.opengroup.org/certification/idx/posix.html -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On 5/28/20 10:03 PM, Larry Dwyer wrote:
To anyone at Oracle Inc. on this mailing list:
I have gone through my library and found only one reference to date_fmt. It is
in the proceedings of the Tenth International Unicode Conference. It is in an
informative discussion about locale performance as measured on Solaris. It is
in the LC_TIME locale subgroup, but I don't think it is in a base header file
(it seems to me to be a "localized" header file). Can someone at Oracle contact
me so "we" can determine when/why/for-whom it was added to Solaris. The header
file it was extracted from and placed into the proceedings is copyright Sun
Microsystems 1996.
It is documented in our locale(7) man page for Solaris 11.4, or locale(5)
for earlier Solaris releases going back to 2.6:
https://docs.oracle.com/cd/E88353_01/html/E37853/locale-7.html
https://docs.oracle.com/cd/E19504-01/802-5747-05/802-5747-05.pdf
Our localedef.h header marks it as a Solaris extension in struct _LC_time_t.
Old sccs files show it was added in 1996, as part of the changes to handle
the differing definitions of %C in strftime for XPG4 vs. previous Solaris
behavior in the new code being brought in from COSE, with the commit comment of:
1250363 - %c should default to XPG3 format, but use XPG4 format in XPG4
environment (if __xpg4 is on); %C should default to Solaris behavior
(default date format), but exhibit XPG4 behavior (century number)
in XPG4 environment.
(I was not at Sun in 1996, so can only offer what I can still find recorded
from that time, not personal insight.)
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Coordination on standardizing gettext() in future POSIX
On 1/22/20 9:08 AM, Bruno Haible wrote: Ulrich Drepper wrote: Do you really like to require SunOS to loose backwads incompatiblity? Overly dramatic. You just need one mode that is POSIX compatible. Many GNU tools use POSIXLY_CORRECT_ The Solaris practice for keeping backward compatibility despite new evolutions of the standards is to use /usr/xpg[457] directories. For example: /usr/xpg4/bin/sh != /usr/bin/sh /usr/xpg6/bin/ls != /usr/bin/ls /usr/xpg7/bin/getconf != /usr/bin/getconf There could be a /usr/xpg8/bin/gettext if POSIX gettext(1) ends up specifying a different behaviour than the current Solaris implementation has. This is absolutely correct, but only relevant if Solaris ever ends up fully implementing XPG8, which is unlikely at this point. (Realistically, we'd probably just make it a link to the /usr/gnu/bin/gettext we already ship and widely use to build FOSS packages that expect the GNU behaviors.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc [The preceding is my personal opinion, and not an official statement of Oracle.]
Re: system() and pthread_atfork()
On 12/20/19 2:40 PM, Karstens, Nate wrote:
That might be, but it would be good to document the tradeoffs associated with
that efficiency. Even better would be to come up with a mechanism to avoid it
entirely. If requiring pthread_atfork() handlers to execute is not an option,
then maybe a file-descriptor/socket option that marks the socket as closing
once the process forks (like SOCK_CLOEXEC / FD_CLOEXEC, but done at fork()
instead of exec()).
Solaris has FD_CLOFORK et al. for that purpose:
https://docs.oracle.com/cd/E88353_01/html/E37841/fcntl-2.html
https://lwn.net/Articles/785430/ suggests AIX, BSD, & MacOS have also defined
it, and though it's been proposed multiple times for Linux, never adopted there.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Draft minutes of the 5th August 2019 Teleconference
On 8/7/19 2:43 PM, enh wrote: What's the plan for the qsort_r interface, given that glibc and BSD have mutually incompatible ones (which is why I didn't add it to Android)? For what it's worth, Solaris has followed the lead of glibc and NetBSD in implementing qsort_r() as: void qsort_r(void *base, size_t nel, size_t width, int (*compar)(const void *x, const void *y, void *context), void *context); with the engineer responsible citing https://reviews.freebsd.org/D17083 as resolving the discrepancy in FreeBSD. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: pthread_t and thrd_t
On 4/17/19 8:58 AM, Geoff Clare wrote:
> So glibc will conform if we require that pthread_t and thrd_t are
> defined as the same type, but does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?
Not here, Oracle Solaris 11.4 has the same type for both:
/usr/include/sys/types.h:
typedef unsigned intuint_t;
typedefuint_t pthread_t; /* = thread_t in thread.h */
/usr/include/threads.h:
typedef unsigned int thrd_t;
To see the full headers for yourself:
/usr/include/sys/types.h:
curl -s
http://pkg.oracle.com/solaris/release/file/0/55ae99dec04f09e8fe9963d87d24ae371c8e85b9
| gzcat | less
/usr/include/threads.h:
curl -s
http://pkg.oracle.com/solaris/release/file/0/183228c541fb3e2b2b6c710fa46964d94ee259a8
| gzcat | less
(For others, substitute the hash listed at the beginning of the line after
"file" for the given header file listed in
http://pkg.oracle.com/solaris/release/manifest/0/system%2Fheader@11.4%2C5.11-11.4.0.0.1.15.0%3A20180817T003001Z
)
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: C11/C17 fopen() "wx" and "exclusive access"
On 03/13/19 08:27 AM, Geoff Clare wrote: I see that Solaris 11.4 supports "x" in the fopen() mode argument, and supports MFL, but according to the fopen(3C) man page all the "x" does is cause fopen() to fail if the file exists; no mention of exclusive access. Perhaps support for "x" wasn't added in order to conform to C11, or perhaps the significance of the C11/C17 wording was missed by the Solaris developers. The developer who made that change is no longer with the company, but from the records of our review, he seems to have believed mapping to the O_EXCL flag to the open() call was sufficient, and compatible with the pre-existing GNU libc & FreeBSD implementations, but then the enhancement request he was working on was originally filed to request adding the "e" & "x" flags for compatibility with those systems. I don't see any discussion in our review of C11 possibly requiring more than that. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant
On 10/ 2/17 04:28 PM, Thor Lancelot Simon wrote: On Mon, Oct 02, 2017 at 04:07:37PM -0700, Alan Coopersmith wrote: On 10/ 1/17 04:10 AM, Joerg Schilling wrote: Is Oracle planning to run a SUSv7-tc2 certification? I don't know which version we plan to certify against next, and probably couldn't pre-announce it here if I did. I have to ask, what is the likelihood this will actually happen? Hasn't Oracle essentially ended Solaris development? The rumors of our demise have been somewhat exaggerated. While we lost a lot of engineers, there's still hundreds of us left working on Solaris 11.4, which our VP's have recently publicly confirmed, during both the SPARC M8 product launch and presentations this week at Oracle OpenWorld, is planned to ship in calendar year 2018. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant
On 10/ 1/17 04:10 AM, Joerg Schilling wrote: Is Oracle planning to run a SUSv7-tc2 certification? I don't know which version we plan to certify against next, and probably couldn't pre-announce it here if I did. My impression is that as a result of various modification in the standard, more than trivial bug-fixes need to be applied on ksh88 to make it SUSv7-tc2 compiant. Have the test suites been updated to catch all of these cases? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant
On 09/29/17 06:38 PM, Martijn Dekker wrote: Op 29-09-17 om 14:16 schreef Stephane Chazelas: 2017-09-29 11:59:52 +0200, Martijn Dekker: [...] Ouch, quite of lot of nasty bugs. Have you reported them to Solaris? No, because I thought ksh88 is no longer being developed. Is that incorrect? It is true that ksh88 is no longer being developed, but the Solaris /usr/xpg4/bin/sh is a fork of ksh88, modified for standards compliance, that is still being maintained, and bugs fixed as necessary. (Make sure you're testing with that version, not stock ksh88 or /usr/bin/ksh, as you will get different results in areas historical ksh behavior deviates from the standards.) Where/how would I report Solaris bugs? Customers with support contracts can report bugs via Oracle Support. The people responsible for running the standards conformance test suites on Solaris are also on this mailing list, and can file bugs if they see issues we need to fix. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")
On 05/29/17 01:56 PM, Joerg Schilling wrote:
Alan Coopersmith <alan.coopersm...@oracle.com> wrote:
We still ship a couple closed source shells in Solaris - the SVR4 Bourne Shell
as /usr/sunos/bin/sh and a modified ksh88 as /usr/xpg4/bin/sh, but our primary
day to day shells are the common open source ones - bash, ksh93, zsh, etc.
Is there any bugfix in /usr/sunos/bin/sh that is not in the Svr4 compatile
copmpile variant of bosh? Or is it unmodified since the Sun updates for
OpenSolaris stopped?
I have no idea what is or is not in bosh. Most of the changes on our side
since that source stopped being published were to adapt to changing build
environments and to prepare for it's EOL.
Is your ksh88 managed in a way that keeps it compatible with the evolving POSIX
standard?
We aren't chasing moving targets here - we're targeting stable releases like
UNIXv7. We have fixed several bugs in our /usr/xpg4/bin/sh that were needed
to pass various cases in the UNIXv7 test suite in past years.
Did you upgrade ksh93 since 2010?
Yes - you can see that we're using the 2012-08-01 release in our open source
trees at:
https://github.com/oracle/solaris-userland/tree/master/components/ksh93
If yes, have you been able to keep it as fast as it was in OpenSolaris?
I have no idea - I don't know what commonly accepted shell benchmark we'd
use to tell.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")
On 05/29/17 04:37 AM, Robert Elz wrote: There is no requirement that you, or I, or anyone else in particular, be able to build and run any particular shell. While that's nice if possible, a shell is still a shell even if its source code is not openly available at all (like any that are in closed source systems, if any of those still really exist.) Users get to experience those shells too. We still ship a couple closed source shells in Solaris - the SVR4 Bourne Shell as /usr/sunos/bin/sh and a modified ksh88 as /usr/xpg4/bin/sh, but our primary day to day shells are the common open source ones - bash, ksh93, zsh, etc. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: Solaris 11 certification and broken links at www.opengroup.org
On 04/21/17 08:47 AM, Joerg Schilling wrote:
Stephane Chazelas <stephane.chaze...@gmail.com> wrote:
OK, "Solaris 11 and its maintenance releases" make more sense
than "Solaris 11 FCS and later". Thanks for clarifying.
This is how I thought Solaris always was maintained:
There are updates to a specific version that grant not to
break interfaces.
In other words Solaris 11 and Solaris 11.3 are something different, while
Solaris 11 update XXX is still Solaris 11.
That is incorrect. The "update XXX" naming has always been internal to Solaris.
Solaris 10 and prior releases used the date for the marketing name ("Solaris 7
8/99", "Solaris 10 8/07", and so on). Solaris 11 adopted the Oracle naming
conventions, so "Solaris 11 update 1" is marketed as "Oracle Solaris 11.1",
"Solaris 11 update 3" is "Oracle Solaris 11.3", and so on.
Whether or not interfaces may be broken depends on the declared interface
stability level - Private or Volatile interfaces can be broken at any time;
Committed interfaces should not be broken in an update release, whether it's
named Solaris 10 8/07 or Solaris 11.3. I believe all non-deprecated interfaces
specified by the POSIX & X/Open standards are Committed.
While people know that on Solaris it was sufficient to prepend your PATH
with /usr/xpg6/bin:/usr/xpg4/bin to get POSIX behavior,
Hopefully they know that is the current implementation, but the standard
mechanism is "getconf PATH" as defined in:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html
so that if we add /usr/xpg7/bin in a future version, they'd get that too.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
