^--- this would be fabulous, it allows people to unfollow conversations about PRs they aren't interested in.

It looks like the release tags are of the form 1.2.3, but go expects v1.2.3 (its Node.js convention, as well). Adding tags with the leading v might fix this.

Any of my code you are free to relicense.

Go for it, seems a natural fit.

@MarcinHoppe not sure. check the issue in H1, it will have a link to the CVE request, you can see its state. ask H1 if its confusing. (sorry, I've no longer any access and can't check directly).

No solution, its still broken, I believe that it is caused by an incomplete implementation of the contained/cri log format, the fluented config lost JSON support at that time. See some of the linked issues above. Not something I work with directly ATM, though, so I won't be looking into it anymore.

Sorry, I deleted my fork this morning since I'm not using rdkafka for work anymore. The changes can be redone by someone in the project if there is interest.

Thanks for the cleanup @Trott

I removed myself from the nodejs and nodejs-private orgs, which should hopefully clean up all my team memberships immediately, so no one has to do that manually.

Landed in 1aa847f7438407b78cc0d1f9eab96adcfe9ff9df

Thanks you all. And yes, I did want to get removed from collaborators, mostly so at-nodejs/collaborators doesn't ping me :-). If I ever want to PR anything, I still can.

the helper approach that got merged supports the mac keychain as a store

I don't have enough time to remain active in the TSC, so I will step down.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

@dominykas Perhaps you should take a look at the node options parser API, here's an example of its usage: https://github.com/nodejs/node/blob/master/src/node_options.cc#L274 If you think that an API that parses a C array of null terminated strings into c++ data types has some feature overlap with what's wanted here, you are seeing something that I'm not. But that's just me, running code is the best POC. You may want to examine @boneskull 's comparison matrix to see how node's features stack up to the others.

I like where you are going with that, reusing what we have, but it won't work. It's in c++, not very featureful (won't combine single char switches, etc.), and would be somewhat hard to expose. Also is a bit tuned to node's use-case, as-in, when options are added (in c++) there is a flag saying whether they are allowed by in NODE_OPTIONS.

@rvagg some context here: https://github.com/nodejs/node/pull/33639

OK, I'm back on that one - I just want to avoid the continual chatter from the CVE distro lists.

Hi folks. I'm not expecting to have time to work on the build going forward. @AshCripps and @richardlau are well able to continue anything I was working on. Its been a pleasure to help out where I could. If something comes up where some bit of information is missing that only I have (I really don't expect that), please don't hesitate to reach out to me, and I'll do my best.

I'll offboard myself to save you all the work :-)

Cheers!

Offboarding issue checklist

(Remove items if not applicable)

• [x] Remove their GPG key from test group in nodejs-private/secrets
• [x] Remove their GPG key from release group in nodejs-private/secrets
• [x] Remove their GPG key from infra group in nodejs-private/secrets
• [x] Remove their GPG key from infra-macstadium group in nodejs-private/secrets
• [x] Remove their GPG key from github-bot group in nodejs-private/secrets
• [x] Remove them from build teams they are a member of:
  • [x] nodejs/build
  • [x] nodejs/build-release
  • [x] nodejs/build-infra
  • [x] nodejs/jenkins-admins
  • [x] nodejs/jenkins-release-admins
  • [x] nodejs-private/build
• [x] PR changes to README.md to move the member to emeritus status
• [x] Run ncu team sync to vaildate the user has been removed from the build teams
• [x] Remove them from the nodejs/email alias

Just as a heads up, I'll be on vacation for the next 2 weeks, with limited time for reviewing gh notifications.

Refs: https://github.com/nodejs/build/issues/2339

This project is not very active, so issues are being auto-closed before any maintainers get around to triaging them.

Can be closed once the api token is removed.

I did things in the wrong order, I left the nodejs-ecosystem program, and now I can't revoke my API token! Can someone do that for me, please? Its the one called sam-github.

Hi folks, I won't have so much time to participate in the WG (and honestly, haven't had for a while), so I'm going to offboard myself. Thanks for all the hard work you all do.

Cheers, Sam

Revoking Access to Confidential Systems

The following is a check-list of actions to be taken upon departure of users from the Security WG (either voluntarily or due to inactivity as described above):

• [ ] Remove user from Repo README, Triage Team
• [ ] Remove membership from Node.js WG GitHub Team
• [ ] Remove user from HackerOne platform
• [ ] Revoke any user-specific access tokens from HackerOne platform
• [ ] Remove user access from private team channels in slack (nodejs-security-wg.slack.com)

The following is a check-list of actions to be taken upon voluntary departure of users from the Third-Party Triage Team, when the users will remain in the Security WG.

• [ ] Remove user from Triage Team
• [ ] Remove user from HackerOne platform
• [ ] Revoke any user-specific access tokens from HackerOne platform
• [ ] Remove user access from private team channels in slack that are specific to the Triage Team (nodejs-security-wg.slack.com)

I've permission from @refack to move him.

I took @gdams out of a few teams I'm pretty sure he doesn't work on anymore, and I'm pretty sure he is ok to be moved to emiriit, but I don't want to do that without confirming.

I've emailed him, and will open an offboard issue for him when I hear back (or not, if he is keen to remain).

https://github.com/nodejs/email/pull/158 <--- needs approval

See: https://github.com/nodejs/build/issues/2192

this didn't happen yet, I can't do, but the rest did.

https://github.com/nodejs/node-core-utils/issues/436

pushed a sync up.

I haven't troubleshot much, but I'm seeing

% ncu-team sync README.md         
✔  Received member information of nodejs/build                                                 
✔  Received member information of nodejs/build-infra                                                                                                                                           
✔  Received member information of nodejs/jenkins-admins
✔  Received member information of nodejs/jenkins-release-admins
✔  Received member information of nodejs/github-bot
Error: ENOENT: no such file or directory, mkdir 
    at Object.mkdirSync (fs.js:940:3)      
    at exports.writeFile (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/lib/file.js:18:8)
    at Function.TeamInfo.syncFile (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/lib/team_info.js:61:3)                                                               
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async main (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/bin/ncu-team:64:7) {
  errno: -2,                         
  syscall: 'mkdir',                                                                            
  code: 'ENOENT'                                                                                                                                                                               
}

with node 14.4.0, so I backdated to 1.20.0, same, so I backdated node to 12.18.0, and it worked.

Refs: https://github.com/nodejs/build/issues/2339

sigh.

w/build (master u=) % ncu-team sync README.md
✔  Received member information of nodejs/build
✔  Received member information of nodejs/build-infra
✔  Received member information of nodejs/jenkins-admins
✔  Received member information of nodejs/jenkins-release-admins
✔  Received member information of nodejs/github-bot
Error: ENOENT: no such file or directory, mkdir
    at Object.mkdirSync (fs.js:940:3)
    at exports.writeFile (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/lib/file.js:18:8)
    at Function.TeamInfo.syncFile (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/lib/team_info.js:61:3)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async main (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/node-core-utils/bin/ncu-team:64:7) {
  errno: -2,
  syscall: 'mkdir',
  code: 'ENOENT'
}

Sorry, I can't remove my secret keys. That makes sense, dotgpg can't encrrypt the file with a key if that key isn't allowed to decrypt the file.

I'll do the github stuff.

Hi folks. I'm not expecting to have time to work on the build going forward. @AshCripps and @richardlau are well able to continue anything I was working on. Its been a pleasure to help out where I could. If something comes up where some bit of information is missing that only I have (I really don't expect that), please don't hesitate to reach out to me, and I'll do my best.

I'll offboard myself to save you all the work :-)

Cheers!

Offboarding issue checklist

(Remove items if not applicable)

• [ ] Remove their GPG key from test group in nodejs-private/secrets
• [ ] Remove their GPG key from release group in nodejs-private/secrets
• [ ] Remove their GPG key from infra group in nodejs-private/secrets
• [ ] Remove their GPG key from infra-macstadium group in nodejs-private/secrets
• [ ] Remove their GPG key from github-bot group in nodejs-private/secrets
• [ ] Remove them from build teams they are a member of:
  • [ ] nodejs/build
  • [ ] nodejs/build-release
  • [ ] nodejs/build-infra
  • [ ] nodejs/jenkins-admins
  • [ ] nodejs/jenkins-release-admins
  • [ ] nodejs-private/build
• [ ] PR changes to README.md to move the member to emeritus status
• [ ] Run ncu team sync to vaildate the user has been removed from the build teams
• [ ] Remove them from the nodejs/email alias

@aixtools I sent you the invite, thanks so much for the offer.

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

• tls.renegotiate(): doc that callback is added as a listener to the 'secure' event

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

  • describe better how file position works, about unix fd model, OCBs, etc., 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: https://github.com/nodejs/node/pull/2446

• http docs, and additional apis: https://github.com/nodejs/node/issues/2461#issuecomment-133295966

• 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

• write(chunk, encoding, cb) encoding can be null
• undocumented... probably defaults to utf8

OCSP docs...

• https://nodejs.org/api/tls.html#tls_event_ocsprequest
• docs unclear, I think the "issuer" is actually the root CA, not the direct issuer/intermediate CA
• step 5 likely involves OCSPResponse being emitted as an event, not said
• says asn1.js can be used to parse... but is it possible that the OCSP info in https://nodejs.org/api/tls.html#tls_certificate_object is all that is needed, and is already available?
• https://nodejs.org/api/tls.html#tls_new_tls_tlssocket_socket_options
• requestOCSP <boolean>: not clear if it does anything when called on the server side, probably not. should say that presence of the extension will cause OCSPRequest event on server side (if server side is node)
• https://nodejs.org/api/tls.html#tls_event_ocspresponse
• lacking any info on what user is supposed to do with the response
• client is supposed to be able to return a value in the cb to fail hankshake:
  • https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tlsext_status_cb.html

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?

• https://github.com/nodejs/node/issues/12339

process

implement process.std(out/in/err).reopen(): so that it's possible, as in many languages

• https://github.com/nodejs/node/issues/7606#issuecomment-458003722

child_process

remove maxBuffer default

• https://github.com/nodejs/node/issues/9829#issuecomment-285439555

• 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

  • I think I commented on this, and fixed it in backports, and it was thought 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

  • server.close(cb), cb gets an error if net is already closed... this is bizarre and inconsistent:
    • https://github.com/nodejs/io.js/pull/1025
  • not clear why close callback is not .once('close'), very unusual! changing 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

    t=tls.createServer({}); t.close(function(){ console.log('close cb',arguments) }); t.on('close',function(){console.log('close ev', arguments) }); close cb { '0': [Error: Not running] } close ev {}

tls

use SSL_OP_NO_RENEGOTIATION to disable renegotiation(), instead of the info callback thing we are doing internally

• Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 1.3)

finish and land this, simple API consistency:

• https://github.com/nodejs/node/pull/20916

deprecate tlsSocket.getSession() once TLS1.3 is more common

• 16.x?

Server.prototype.addContext should be case insensitive, but it probably is not, confirm and fix if necessary

• https://tools.ietf.org/html/rfc6066#section-3
• https://tools.ietf.org/html/rfc5890#section-2.3.2.4

servername must not be an IP address:

• https://github.com/nodejs/node/pull/19988
• should have negative tests
• should throw better errors
• should actually check that arg is not an IP address (semver-major)

perhaps done now?

• https://github.com/nodejs/node/commit/c51b7b296e0fd59a00b1c1337d744f4fc8d2fb35
• TODO(shigeki) Change this to EVP_PKEY_X25519 and add EVP_PKEY_X448 after upgrading to 1.1.1.

make addr for SNI deprecation an actual thrown error

• https://github.com/openssl/openssl/pull/8175#discussion_r257378083
• needs first to have a runtime deprecation that checks the SNI arg
• needs to check client and server side

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

• https://github.com/nodejs/node/issues/9551#issuecomment-291585619

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

• https://github.com/nodejs/node/pull/10846 for attempt to doc current API

external users of undocumented TLS APIs:

• https://github.com/eleith/emailjs/blob/master/smtp/smtp.js#L263-L289

• https://github.com/mattcg/starttls/issues/3

• DTLS:

  • https://github.com/nodejs/node/issues/2398
  • https://github.com/Rantanen/node-dtls

tls requires a subject even when altNames are defined

• https://github.com/nodejs/node/pull/22906#issuecomment-482840254

crypto

expose expected iv/key sizes for crypto algs:

• https://github.com/nodejs/node/pull/26612#issuecomment-473683237

allow key object args to key object create functions, returning identity (done?)

sys random: https://github.com/nodejs/node/issues/5798

• Was blocked on ossl 1.1.1, should be possible to do very soon: https://github.com/nodejs/node/issues/5798#issuecomment-319999796
• open question: can the OpenSSL internal PRNG be replaced?
• http://man7.org/linux/man-pages/man2/getrandom.2.html
• https://bugs.ruby-lang.org/issues/9569
• https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy
• https://bugzilla.kernel.org/show_bug.cgi?id=71211
• https://github.com/openssl/openssl/issues/898
• https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
• AEADs like AES-GCM and ChaCha20-Poly1305A
• https://www.imperialviolet.org/posts-index.html
  • https://www.imperialviolet.org/2011/02/04/oppractices.html

IV should be optional if unused (ECB), not force a zero-length buffer:

• https://github.com/nodejs/node/issues/10263#issuecomment-266944568
  • If the cipher does not need an initialization vector, iv may be null. 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:

• https://github.com/nodejs/node/issues/14628#issuecomment-321639517
• difficulty needs research, I think there were suggestions its hard to guess 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

Layne Miller when i wanted to do similar (create .p12) i could not find a suitable module, ended up with exec('openssl ...', callback);

• ouch!

Sign.maximumSignatureSize()

• https://github.com/nodejs/node/issues/26631#event-2206911322

consistently rename socket to tlsSock in lib/_tls_wrap.js

Return other info for ::GetCipher(), like

• SSL_CIPHER_is_aead(), SSL_CIPHER_standard_name, ...

research 0-RTT

• 0-RTT ... is it supported by openssl? can it be disabled? it allows replay

  • should not allow non-GET with 0-rtt, how to tell from API? How to reject?
  • https://blog.cloudflare.com/introducing-0-rtt/
  • https://tools.ietf.org/html/rfc8446#section-8
  • https://tools.ietf.org/html/rfc8446#section-8.1
    • how do we get the ticket, to store, and ensure not used multiple times? maybe store it in the ticketcbs, as we encrypt it, and check it when we decrypt it? necessary if not using 0-rtt?
  • https://tools.ietf.org/html/rfc8446#section-8.2
    • how to implement this?

• forward secrecy

• https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

• groups: might need configuring, do we support that?

  • https://wiki.openssl.org/index.php/TLS1.3#Groups

• certificate transparency (CT)/serverinfo API, do we support? should we?

  • https://wiki.openssl.org/index.php/TLS1.3#Custom_Extensions_and_Certificate_Transparency
  • https://www.openssl.org/docs/manmaster/man3/SSL_CTX_use_serverinfo.html
  • https://en.wikipedia.org/wiki/Certificate_Transparency#Certificate_authority_implementation

• could support disabling middlebox compatibility mode, but probably don't want to unless someone explicitly asks for this

  • https://wiki.openssl.org/index.php/TLS1.3#Middlebox_Compatibility_Mode

• node clients should DEFAULT to using SNI: does node with https? (yes) tls.connect? (no)

  • https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
  • should doc this

• 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

Q: can the existing renegotiate() API be partially implemented in terms of
these new APIs, or should there just be new APIs? Its hard for a user, because
they would need to first check the protocol that was negotiated, then decide
what APIs they have to call. This problem even seems to have occurred to
OpenSSL :-(

- https://github.com/openssl/openssl/blob/fff1470cd/ssl/ssl_lib.c#L2104-L2106

Perhaps things like ca/etc in renegotiate() can be set as they are now, and
then key update and/or cert req can be made depending on the options?

I haven't seen code that calls renegotiate on the server side, but its supported

• https://www.openssl.org/docs/manmaster/man3/SSL_renegotiate.html
• Confirm that both sides allow it for TLS1.2.

key update is SSL_key_update

• https://www.openssl.org/docs/manmaster/man3/SSL_key_update.html
• can be called from either side
• I assume it would trigger new session tickets to be sent?
  • XXX verify this!
• https://www.mail-archive.com/[email protected]/msg10202.html Therefore KeyUpdate messages are not currently viable on the web, at least when client initiated.

request a certificate from the client post-handshake

• SSL_verify_client_post_handshake
• https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html
• specifically mentioned in node docs:
  • https://nodejs.org/api/tls.html#tls_tlssocket_renegotiate_options_callback
• XXX what does this look like from the API? How do we know a verification has occurred? I assume some cert cbs will be re-called...
  • XXX verify this!

Implement a new tls.sessionInfo(sess):

• getSessionInfo() doesn't work anymore, this replacement is needed
• hasTicket: SSL_SESSION_has_ticket
• resumable: SSL_SESSION_is_resumable
• ticket: SSL_SESSION_get0_ticket
• ticketLifetime: SSL_SESSION_get_ticket_lifetime_hint
• id: get_session_id
• ...: ?

expose key lifetime control

implement createServer({numTickets: })

• https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_num_tickets.html

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.

• https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html

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:

  • https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

optionally need ticket key callback for named ticket keys

• Not having them means accidental invalidation of tickets after setTicketKeys
• SSL_CTX_set_tlsext_ticket_key_cb

merge tests with test-tls-auth.js, or otherwise clean them up?

• rename test-tls-client-auth to something more indicative
• test/parallel/test-tls-ca-concat.js
• test/parallel/test-tls-cert-chains-concat.js
• test/parallel/test-tls-cert-chains-in-ca.js
• cert.split(/(?=-----BEGIN CERTIFICATE-----)/)
• maybe test/parallel/test-tls-cert-regression.js
  • ^--- add tests for buffer format args

cluster:

make kill NOT do a disconnect, just be childprocess.kill

• discussion: https://github.com/joyent/node/issues/6042
• kill rename:
  • https://github.com/joyent/node/pull/4908
  • https://github.com/joyent/node/issues/4133
• discussion for rename: https://github.com/joyent/node/issues/4133#issuecomment-9405470
• worker.kill(SIG)... SIG is not normally received
  • https://github.com/joyent/node/issues/5832#issuecomment-29155494
  • https://github.com/joyent/node/issues/6042
  • https://github.com/joyent/node/issues/5766

I retook the screenshot, with all the headers.

@richardlau I pushed your screenshot update into this PR

• Node.js 8 to 10.15.x:
• OS:
• Scope (install, code, runtime, meta, other?):
• Module (and version) (if relevant):

Is Nodejs vulnerable to ICU: Integer overflow in UnicodeString::doAppend() (CVE-2020-10531)? Red Hat and many other vendors have released patches to patch the ICU buffer overflow issue in their platforms As we notice, we have ICU being used in Nodejs. Example: Node 8.x has "icu: '59.1' & Node 10.x has icu: '62.1' Please see the below links for this ICU vulnerability https://www.tenable.com/cve/CVE-2020-10531 ICU: Integer overflow in UnicodeString::doAppend() (CVE-2020-10531) https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories&qid=RHSA-20201317%20-%20Security%20Advisory Red Hat has released an update for the nodejs:10 module to address the ICU issue.

I didn't find any reference from Nodejs security on this ICU issue.

Can anybody from Nodejs confirm if Nodejs is vulnerable for this ICU Integer Overflow vulnerability?

Thank you

The fix was released in the most recent 10.x sec release.

See https://nodejs.org/en/blog/vulnerability/june-2020-security-releases/

I think that fixes this issue.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

Backport of: https://github.com/nodejs/node/pull/32583

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

obsoleted by https://github.com/nodejs/node/pull/32982, which includes the update to 1.1.1f, and the update to 1.1.1g

Issue: https://github.com/appsody/stacks/issues/518

Description: https://github.com/appsody/stacks/issues/518#issuecomment-601957506

This is a minimal, language agnostic, reproduction of issue #518.

Once it works, it might be worth cleaning up and merging as a language agnostic example of satisfying the non-root user certification requirement.

To reproduce:

• checkout this PR branch
• cd incubator/starter
• ./test-appsody-test (fails)
• ./test-appsody-test-root-leakage (fails)
• ./test-appsody-run (fails)
• ./test-appsody-build (passes)

Draft because it should be applied simultaneously to all nodejs derived stacks, and will work better once some PRs ongoing into nodejs/node are released.

Checklist:

• [ ] Read the Code of Conduct and Contributing Guidelines.

• [ ] Followed the commit message guidelines.

• [ ] Stack adheres to Appsody stack structure.

Modifying an existing stack:

• [ ] Updated the stack version in stack.yaml

<!--- Describe your changes in detail -->

Contributing a new stack:

• Describe how application dependencies are managed:

• Explain how Appsody file watcher is utilized:

• Describe other Appsody environment variables defined by the stack image:

• Describe any limitations and known issues:

Related Issues:

<!-- e.g. Fixes #32, Related to #54, etc. -->

https://github.ibm.com/runtimes/squad-node/issues/589

Draft, not working yet. The dep volume is mounted in as user root, even though its mounted into a folder owned by node, and all its contents are owned by user node. This makes APPSODY_PREP="npm install" incapable of adding installing new deps.

How can I fix that?

incubator/nodejs (reconcile *$%) % docker run --rm -p 3000:3000 -p 9229:9229 --name ex-nodejs-dev -u 1000:1000 -e "APPSODY_USER=1000" -e "APPSODY_GROUP=1000" -v /home/sam/w/cloud/appsody-stacks/ex-nodejs/:/project/user-app -v ex-nodejs-deps:/project/user-app/node_modules -v appsody-controller-0.3.4:/.appsody -it --entrypoint bash  dev.local/appsody/nodejs:0.3
node@24994f98a704:/project/user-app$ ls -l  
total 20
-rw-rw-r-- 1 node node  880 Mar 12 22:55 app-deploy.yaml
-rw-rw-r-- 1 node node   65 Mar 12 22:55 app.js
drwxr-xr-x 2 root root 4096 Mar 12 21:58 node_modules
-rw-rw-r-- 1 node node  668 Mar 12 22:55 package-lock.json
-rw-rw-r-- 1 node node  413 Mar 12 22:55 package.json

My test script, FTR, to be run from incubator/nodejs

#!/bin/sh

set -e
set -x

STACK=$(basename $PWD)

appsody stack package

: STACK=$STACK

rm -rf ../../ex-$STACK
mkdir  ../../ex-$STACK
cd     ../../ex-$STACK
rm -f .appsody-config.yaml
appsody init --overwrite dev.local/$STACK
# Work around bug where appsody creates root-owned node_modules in user's dir
rm -rvf node_modules
npm i modern-syslog
echo "; require('modern-syslog');" >> app.js
appsody build
docker run dev.local/ex-$STACK
appsody test

Checklist:

• [ ] Read the Code of Conduct and Contributing Guidelines.

• [ ] Followed the commit message guidelines.

• [ ] Stack adheres to Appsody stack structure.

Modifying an existing stack:

• [ ] Updated the stack version in stack.yaml

<!--- Describe your changes in detail -->

Contributing a new stack:

• Describe how application dependencies are managed:

• Explain how Appsody file watcher is utilized:

• Describe other Appsody environment variables defined by the stack image:

• Describe any limitations and known issues:

Related Issues:

<!-- e.g. Fixes #32, Related to #54, etc. -->

Clearly, just my opinion, and if you all love the changelog strategy as it is, I've no problem working with it, but here's a shot at making the case that better tooling is a better way to go.

The keep-a-changelog stance doesn't look very tenable for projects like this, unlike a web framework, say, or an app, where someone would do a nice writeup for every release, giving guidance and information on what's changed, maybe some blog posts, etc, etc.

AFAICT, what is actually happening is that the git commit description is pasted by hand into the CHANGES.md file. This has downsides:

1. Its non-standard, it used to require a reminder on every PR from the maintainers, though now the reminder is automated with a github action, which is better for reviewers, but same for contributors
2. It doesn't appear to result in a better changelog, I don't think the existing changelog is noticably more informative than an autogenerated one
3. Every PR is guaranteed to conflict if anything is merged before it, because the changelog centralizes conflicts. This requires manual conflict resolution by either maintainers from CLI, or the PR people, its just one extra step.

The first commit in this draft shows what the auto-generated changelog could look like -- I obviously used the tooling I used when I was maintaining and releasing scores of packages simultaneusly, but there are many spins on this.

The second commit goes a step further, it shows what a one shot slt-release -up vx.y.z would look like (except without the -up, which would do a git push and npm publish -- one-shot command for an entire release. could probably even be a GH action...). The tedious details are in the docs, but basically, it uses npm version to update the package version, uses the auto-generated log (for changes since last release) as the commit message and tag message (which is what shows up on the prom-client/releases page), etc.

Offerred for your consideration! :-)

cf. https://github.com/siimon/prom-client/issues/344

Format is the same as:

• https://nodejs.org/api/tls.html#tls_tlssocket_getcertificate

No docs or tests yet, @nodejs/crypto, I'll finish this if we want it.

Its easy, it just exposes current data format of the tls APIs, and makes testing whether certificates can be decoded quite easy, rather than having to round-trip them through TLS just to get a parsed cert :-(.

Maybe some other format would be better, and then it could be added to tls and crypto, but starting with a "better" format in crypto that is different from what tls does seems like it would increase inconsistency.

Fixes: https://github.com/nodejs/node/issues/29181

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

@richardlau WDYT, does this describe what you did? I think we both did it at the same time.