Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Console] Fix STDERR output text on IBM iSeries OS400#15058

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
johnkary wants to merge2 commits intosymfony:2.3fromjohnkary:os400Stderr

Conversation

@johnkary
Copy link
Contributor

QA
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsNone
LicenseMIT
Doc PRNone

Prior to this PR a Symfony Console command would output error text as random symbols when executed via the IBM console program QSH. Affected error text output such as when a required InputArgument is missing, or when explicitly using$output->getErrorOutput()->writeln('Some error text here').

Example error output

This PR fixes error text so it properly prints to IBM console programs such as QSH and QP2SHELL.

I previously fixed STDOUT for PHP running on IBM iSeries OS400 (Zend Server) using the same approach. Since that PR was merged ConsoleOutput class began using its own output for STDERR which exhibits the same issue STDOUT did.

The following commits and previous Symfony PRs have our relevant discussion about ASCII vs EBCDIC character encoding to fix this issue:

Thanks!
🚀

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

IMO, since it is a boolean check, the method should be prefixed withis.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@phansys Thanks, I changed it toisRunningOS400()

@fabpot
Copy link
Member

Thank you@johnkary.

fabpot added a commit that referenced this pull requestJun 23, 2015
…nkary)This PR was squashed before being merged into the 2.3 branch (closes#15058).Discussion----------[Console] Fix STDERR output text on IBM iSeries OS400| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | None| License       | MIT| Doc PR        | NonePrior to this PR a Symfony Console command would output error text as random symbols when executed via the IBM console program QSH. Affected error text output such as when a required InputArgument is missing, or when explicitly using `$output->getErrorOutput()->writeln('Some error text here')`.![Example error output](http://i.imgur.com/PQplK1p.png)This PR fixes error text so it properly prints to IBM console programs such as QSH and QP2SHELL.I previously fixed STDOUT for PHP running on IBM iSeries OS400 (Zend Server) using the same approach. Since that PR was merged ConsoleOutput class began using its own output for STDERR which exhibits the same issue STDOUT did.The following commits and previous Symfony PRs have our relevant discussion about ASCII vs EBCDIC character encoding to fix this issue:* [Original IBM STDOUT reported in#1434](#1434)* [My PR#4152 thatfixes#1434](#4152)Thanks!:rocket:Commits-------23c42ca [Console] Fix STDERR output text on IBM iSeries OS400
@fabpotfabpot closed thisJun 23, 2015
@eloigranado
Copy link

@johnkary please, could you modify therunningOS400 function to use thePHP_OS constant instead of thephp_uname function?

There is a point into hiding the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability, so some of us disable this function (along with all the command execution, POSIX, etc). And whilePHP_OS will give you the OS in which PHP was built, no one is going to run a non-OS400 built PHP binary in OS400 (and if they do, mangled console output will be the least of their issues).

@jakzal
Copy link
Contributor

@eloigranado feel free to submit a PR yourself if johnkary is too busy ;)

@xabbuh
Copy link
Member

@eloigranado see#16053

fabpot added a commit that referenced this pull requestOct 2, 2015
This PR was merged into the 2.3 branch.Discussion----------[Console] use PHP_OS instead of php_uname('s')| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#15058| License       | MIT| Doc PR        |The php_uname() function may be disabled for security reasons.Commits-------40e0dc8 use PHP_OS instead of php_uname('s')
@johnkary
Copy link
ContributorAuthor

@eloigranado I have added this check in#16095 even though I disagree with accommodating the case when php_uname() is disabled.

fabpot added a commit that referenced this pull requestOct 7, 2015
…hnkary)This PR was squashed before being merged into the 2.3 branch (closes#16095).Discussion----------[Console] Add additional ways to detect OS400 platform| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#16053| License       | MIT| Doc PR        | NoneThis PR adds support for detecting the OS400 platform when the PHP function `php_uname()` is disabled. OS400 platform detection was added in#15058 to fix character encoding issues present on OS400. See that PR for more info.This PR fixes regression introduced in#16053, which did not work on the IBM OS400 server I have access to. The constant `PHP_OS` being checked outputs "AIX" on my IBM OS400 server. I can't say for sure if it works on other IBM platforms... but I preserved this check just in case.User@eloigranado [commented here](#15058 (comment)) asking if we could switch to using `PHP_OS` constant instead of `php_uname()` because he claims some admins might "[hide] the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability". I personally don't think we should accommodate this use case, but I was able to find alternate approaches.### Why use case insensitive string matching stristr() instead of in_array()?Here are the various outputs on my OS400 server:    echo PHP_OS; // "AIX"    echo getenv('OSTYPE'); // "os400"    echo php_uname('s'); // "OS400"So we have various case issues here, and possible blank values on platforms where OSTYPE var doesn't exist or php_uname() is disabled. Concatenating these optional values together delimited by ; then case-insensitive searching the string for "OS400" seemed like a fair compromise. I would've probably done `in_array()` if case wasn't an issue.Commits-------96a4071 [Console] Add additional ways to detect OS400 platform
fabpot added a commit to symfony/console that referenced this pull requestOct 7, 2015
…hnkary)This PR was squashed before being merged into the 2.3 branch (closes #16095).Discussion----------[Console] Add additional ways to detect OS400 platform| Q             | A| ------------- | ---| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | #16053| License       | MIT| Doc PR        | NoneThis PR adds support for detecting the OS400 platform when the PHP function `php_uname()` is disabled. OS400 platform detection was added in #15058 to fix character encoding issues present on OS400. See that PR for more info.This PR fixes regression introduced in #16053, which did not work on the IBM OS400 server I have access to. The constant `PHP_OS` being checked outputs "AIX" on my IBM OS400 server. I can't say for sure if it works on other IBM platforms... but I preserved this check just in case.User@eloigranado [commented here](symfony/symfony#15058 (comment)) asking if we could switch to using `PHP_OS` constant instead of `php_uname()` because he claims some admins might "[hide] the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability". I personally don't think we should accommodate this use case, but I was able to find alternate approaches.### Why use case insensitive string matching stristr() instead of in_array()?Here are the various outputs on my OS400 server:    echo PHP_OS; // "AIX"    echo getenv('OSTYPE'); // "os400"    echo php_uname('s'); // "OS400"So we have various case issues here, and possible blank values on platforms where OSTYPE var doesn't exist or php_uname() is disabled. Concatenating these optional values together delimited by ; then case-insensitive searching the string for "OS400" seemed like a fair compromise. I would've probably done `in_array()` if case wasn't an issue.Commits-------96a4071 [Console] Add additional ways to detect OS400 platform
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@johnkary@fabpot@eloigranado@jakzal@xabbuh@phansys@linaori

[8]ページ先頭

©2009-2025 Movatter.jp