-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
A possible TODO list for new (or current) contributors #33715
Comments
Hello, @sam-github I want to work on the following issue:
Let me tell you what I have understood:
But I didn't understand the following:
@sam-github Can you please guide me here? |
rebase master branch & resolve conflicts in stream.md file Fixes: nodejs#33715
Make `Worker.prototype.kill` to be just process.kill without preforming graceful disconnect beforehand. Refs: nodejs#33715
@sam-github I want to take up #9829 (comment) issue to remove maxBuffer default in child_process. Can you confirm if we want to remove the circuit breaker entirely or set it to a very high value? |
Reabse master & In stream write encoding can be null. Fixes: nodejs#33715
In stream write encoding can be null. Fixes: nodejs#33715
rebase master branch & resolve conflicts in stream.md file Fixes: nodejs#33715
@aduh95 - is all the items in this issue are covered or not? looks like there are many issues which needs to cover. I'm reopening this issue .let me know if that is not the case. |
Following the topic, i could suggest you to read this great article |
Refs: nodejs#33715 link message.socket deprecate Update doc/api/http.md Co-authored-by: mscdex <mscdex@users.noreply.github.com> fix added version Update doc/api/deprecations.md Co-authored-by: James M Snell <jasnell@gmail.com>
Make `Worker.prototype.kill` to be just process.kill without preforming graceful disconnect beforehand. Refs: nodejs#33715
Make `Worker.prototype.kill` to be just process.kill without preforming graceful disconnect beforehand. Refs: nodejs#33715
I'm not exactly sure how to manage this, so I thought I'd start with an issue, since they are easy, and can be closed if not useful.
I keep a file where I dump quick notes on things that I intend to look into tomorrow. But, tomorrow never comes.
I just triaged my list, I believe that from a 1st pass, these are all still current. They run the full gamut from possible bugs, to missing features (some big, some trivial), to missing docs, to research on possible features. A good set of the features are quite small to implement, like js bindings into OpenSSL that have minimal interaction with any feature around them (see tls.sessionInfo as an example) and would make good first contributions. Some could be much more complex, like
process.stdout.reopen()
.I don't have the time to break these up into dozens of individual bug reports, and doubt that would really be helpful anyway! Still, if there is a better place to put this, I'm open to suggestions.
And if any collaborator feels like editing this to remove things that are already done, or perhaps to open a specific issue or PR for it, please feel free.
doc
pretty sure the 4x increase is just due to 4-thread work pool
https://nodejs.org/en/docs/guides/simple-profiling/
doc all HPE errors from http_parser in docs/errors.js (only HPE_HEADER_OVERFLOW
is there now)
udp: it would be helpful for each method that cannot be called until the
socket is listening to explicitly mention that in its documentation.
https://github.com/nodejs/node/pull/14631/files
current docs assume a basic familiarity with unix i/o
IncomingMessage.connection is not documented, .socket is not documented
either as to whether it is a Socket or a TLSSocket
closed PR to doc the process.platform: doc: Update docs for os.platform() #2446
http docs, and additional apis:
http.ClientRequest
poor documentation #2461 (comment)cluster.fork() asserts in child, but should have a message, false == true is not so useful
cluster.setupMaster and child_process.fork both support execArgv, but it is
not documented for either, is this intentional?
doc: process.on(disconnect or process.on(message causes process to be refed
_write is linked in stream docs, _read isn't, fix in
https://nodejs.org/api/stream.html#stream_buffering
tls newSession should have backwards compat note about when callback was
introduced
doc https://nodejs.org/api/stream.html#stream_writable_write_chunk_encoding_callback
OCSP docs...
issuer/intermediate CA
in https://nodejs.org/api/tls.html#tls_certificate_object is all that is
needed, and is already available?
server side, probably not. should say that presence of the extension will
cause OCSPRequest event on server side (if server side is node)
dns
src/cares_wrap.cc: looks like instead of .code, what would be the code is
thrown as the message.
http
HTTP EPIPE by loopback, can core do anything about this?
process
implement process.std(out/in/err).reopen(): so that it's possible, as in many
languages
child_process
remove maxBuffer default
maxBuffer default too small #9829 (comment)
document how to make a pipe on non-stdio... then make it easier
net
net.connect() - no args does ECONNREFUSED but should be invalid usage
that net.connect() should be same as net.connect({port:undefined}), but I
don't agree, it never makes sense to connect when you don't say what you are
connecting to, it has no use case. also strange that undefined works like no
args were passed, but null is like {port: null} was passed. This all
seems ugly and messy. Check the tests.
close handling bizarre: .... this may have been cleaned up now
bizarre and inconsistent:
might be backwards incompat, need to consider how it should work. Why
doesn't close event get an err arg? there are already conditions for that,
unread data, etc, I think
tls
use SSL_OP_NO_RENEGOTIATION to disable renegotiation(), instead of
the info callback thing we are doing internally
finish and land this, simple API consistency:
deprecate tlsSocket.getSession() once TLS1.3 is more common
Server.prototype.addContext should be case insensitive, but it probably is not,
confirm and fix if necessary
servername must not be an IP address:
perhaps done now?
upgrading to 1.1.1.
make addr for SNI deprecation an actual thrown error
I believe sessions created by renegotiation will never cause newSession to be
emitted server side, since the ClientHello parser won't see them. Maybe I'm
wrong, or maybe nobody has noticed or wanted the feature? Could be that people
are getting poorer performance and not noticing.
X509ToObject should pull DH key info out, it ignores it now
would be nice to have tls.constants... not just crypto.constants
DOC authorized is false on server if there was no client cert requested, but
there will be no authorizationError, because no cert was evaluated
server.addContext takes the options for createSecureContext, but not an actual
SecureContext, which appears to be just an oversight because a user-provided
SNICallback can return a SecureContext.
test letsencrypt with node, seems to be some problems
tls.TLSSocket creation needs to do full setup, to implement documented API
fix tls.Socket constructor, so that it behaves as documented, in that it
connects up the events
external users of undocumented TLS APIs:
https://github.com/eleith/emailjs/blob/master/smtp/smtp.js#L263-L289
docs and code don't appear to be correct mattcg/starttls#3
DTLS:
tls requires a subject even when altNames are defined
crypto
expose expected iv/key sizes for crypto algs:
allow key object args to key object create functions, returning identity (done?)
sys random: #5798
Use system random generator in crypto #5798 (comment)
IV should be optional if unused (ECB), not force a zero-length buffer:
crypto.createCipheriv("AES-128-ECB", "xxxxxxxxxxxxxxxx", Buffer.alloc(0))
crypto.createCipheriv("AES-128-ECB", "xxxxxxxxxxxxxxxx")
Especially now that createCipher() is deprecated.
accept PEM&DER everywhere possible:
the format of whatever is passed, but I'm not sure that is true
PFX api in node, so that CA certs can be parsed from a PFX/p12 file
-crypto does not expose the ossl p12 API
Sign.maximumSignatureSize()
consistently rename socket to tlsSock in lib/_tls_wrap.js
Return other info for ::GetCipher(), like
research 0-RTT
0-RTT ... is it supported by openssl? can it be disabled? it allows replay
maybe store it in the ticketcbs, as we encrypt it, and check it when we
decrypt it? necessary if not using 0-rtt?
forward secrecy
https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
groups: might need configuring, do we support that?
certificate transparency (CT)/serverinfo API, do we support? should we?
could support disabling middlebox compatibility mode, but probably don't want
to unless someone explicitly asks for this
node clients should DEFAULT to using SNI: does node with https? (yes) tls.connect? (no)
x25519: can it not be used for ECDSA? its not showing up in
tls/Client_Hello/Signature_Algorithms
fix test/parallel/test-tls-client-getephemeralkeyinfo.js to do TLSv1.3
Renegotiation: https://wiki.openssl.org/index.php/TLS1.3#Renegotiation
I haven't seen code that calls renegotiate on the server side, but its supported
key update is SSL_key_update
Therefore KeyUpdate messages are not currently viable on the web, at least
when client initiated.
request a certificate from the client post-handshake
occurred? I assume some cert cbs will be re-called...
Implement a new tls.sessionInfo(sess):
expose key lifetime control
implement createServer({numTickets: })
for setTicketKeys change to non-fixed size keys
SSL_OP_NO_TICKET doesn't disable tickets in TLS1.3, it does "stateful" tickets -
what are these for? Do they "work"? It seems they should trigger
newSession/resumeSession callbacks, but I haven't checked that they do.
ticket key management callbacks
Currently, only one set of ticket crypto keys is supported at a time, but
this means roll over will trigger rehandshake. Could/should make this
callback based.
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tlsext_ticket_key_cb
Postfix keeps two session ticket keys in memory, one that's used to
both encrypt new tickets and decrypt freshly issued tickets, and other
that's used only decrypt unexpired tickets that were isssued just before the
new key was introduced. This maintains session ticket continuity across a
single key change. The key change interval is either equal to or is twice the
maximum ticket lifetime, ensuring that tickets are only invalidated by
expiration, not key rotation.
cloudfare does something similar:
optionally need ticket key callback for named ticket keys
merge tests with test-tls-auth.js, or otherwise clean them up?
cluster:
make kill NOT do a disconnect, just be
childprocess.kill
The text was updated successfully, but these errors were encountered: