Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stream_wrap: cast input to Buffer #4031

Closed
wants to merge 2 commits into from
Closed

Conversation

indutny
Copy link
Member

@indutny indutny commented Nov 25, 2015

When wrapping stream - cast its input data to Buffer before using.
Someone may have called .setEncoding() on it, and we should not crash
if the input is a string.

Fix: #3970

@indutny
Copy link
Member Author

indutny commented Nov 25, 2015

It is an open question though, what should be a proper behavior here. Should it just throw instead, or should it try to reset the encoding on stream? (There is no such API method atm, cc @nodejs/streams )

@indutny
Copy link
Member Author

indutny commented Nov 25, 2015

R=@bnoordhuis or @trevnorris

@indutny
Copy link
Member Author

indutny commented Nov 25, 2015

cc @nodejs/crypto

@mscdex mscdex added the stream Issues and PRs related to the stream subsystem. label Nov 25, 2015
@@ -4,6 +4,7 @@ const assert = require('assert');
const util = require('util');
const Socket = require('net').Socket;
const JSStream = process.binding('js_stream').JSStream;
const Buffer = require('buffer').Buffer;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you can drop this line completely.

Copy link
Member Author

Choose a reason for hiding this comment

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

Why?

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't Buffer available everywhere without requiring it? I was able to apply your changes and run it without the require() and it worked fine for me.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is available, but I thought that we decided to not use globals as much as we can.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I didn't know that. Ignore my comment then :-)

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

Should it just throw instead

Are all string encodings guaranteed to make this fail? And, if you throw, can it be done so that the error can be caught? If not, maybe emit an error instead.

@indutny
Copy link
Member Author

indutny commented Nov 30, 2015

@cjihrig I would say all of the encodings will make it fail depending on the particular input. I think it can emit error instead.

@trevnorris
Copy link
Contributor

@indutny Are you saying the data is converted from Buffer to String by setEncoding() and this converts it back to a Buffer?

@indutny
Copy link
Member Author

indutny commented Nov 30, 2015

Yeah, not sure if it is a right thing to do, but at least it does not crash...

@trevnorris
Copy link
Contributor

@indutny may have a problem since v8 automatically strips invalid utf8 characters. so not guaranteed to preserve the data in all cases.

@indutny
Copy link
Member Author

indutny commented Nov 30, 2015

Ok, going to make it emit error then. What about resetting the encoding, are we interested in APIs like this?

@cjihrig
Copy link
Contributor

cjihrig commented Nov 30, 2015

I think resetting the encoding after someone explicitly sets it to something else will lead to a lot of confusion.

If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: nodejs#3970
@indutny
Copy link
Member Author

indutny commented Dec 5, 2015

@cjihrig @trevnorris updated.

@indutny
Copy link
Member Author

indutny commented Dec 5, 2015

PTAL

const StreamWrap = require('_stream_wrap');
const Duplex = require('stream').Duplex;

var done = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is unused.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ack.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 7, 2015

LGTM with comments.

@indutny
Copy link
Member Author

indutny commented Dec 7, 2015

@cjihrig fixed, thanks!

@indutny
Copy link
Member Author

indutny commented Dec 7, 2015

@indutny
Copy link
Member Author

indutny commented Dec 7, 2015

Unrelated CI failures, landing.

@indutny
Copy link
Member Author

indutny commented Dec 7, 2015

Landed in de2fd63, thank you!

@indutny indutny closed this Dec 7, 2015
@indutny indutny deleted the fix/gh-3970 branch December 7, 2015 02:56
indutny added a commit that referenced this pull request Dec 7, 2015
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: #3970
PR-URL: #4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
indutny added a commit that referenced this pull request Dec 8, 2015
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: #3970
PR-URL: #4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@rvagg rvagg mentioned this pull request Dec 8, 2015
@jasnell
Copy link
Member

jasnell commented Dec 11, 2015

@indutny ... should this go into v4 also?

@indutny
Copy link
Member Author

indutny commented Dec 11, 2015

Actually, yes! Thank you @jasnell

indutny added a commit that referenced this pull request Dec 15, 2015
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: #3970
PR-URL: #4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@jasnell jasnell mentioned this pull request Dec 17, 2015
indutny added a commit that referenced this pull request Dec 17, 2015
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: #3970
PR-URL: #4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
indutny added a commit that referenced this pull request Dec 23, 2015
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: #3970
PR-URL: #4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
scovetta pushed a commit to scovetta/node that referenced this pull request Apr 2, 2016
If `.setEncoding` was called on input stream - all emitted `data` will
be `String`s instances, not `Buffer`s. This is unacceptable for
`StreamWrap`, and should not lead to the crash.

Fix: nodejs#3970
PR-URL: nodejs#4031
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants