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

doc: ChangeLog as Markdown and ChangeLog for io.js v1.0.0 #351

Closed
wants to merge 2 commits into from

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Jan 14, 2015

Fixes #339

two separate commits here because the conversion should be separate

@fixe
Copy link
Contributor

fixe commented Jan 14, 2015

@rvagg I suggest renaming the file to CHANGELOG.md for consistency with the other .md files.

@rvagg
Copy link
Member Author

rvagg commented Jan 14, 2015

review by at least one @iojs/tc member please to sign-off on the conversion to markdown, it's pretty heavy-handed but I believe the integrity of the document is kept

further discussion on markdownifying is in #194 (I only just realised it was a PR and not an Issue so I've duplicated that work!)

@indutny
Copy link
Member

indutny commented Jan 14, 2015

Except @fixe comment, LGTM. Would be cool to have some native speaker to sign-off it too

@rvagg
Copy link
Member Author

rvagg commented Jan 14, 2015

renamed file, thanks, the inconsistency has been bugging me too

Conversion of the ChangeLog includes headings, compacted lists,
links for commits to GitHub (iojs/io.js) and links to issues on
GitHub (joyent/node)
Collaboratively edited by many people in
https://code.stypi.com/domenic/iojs-1.0-changelog.md
and includes a summary of changes in each major section of the
project from a user-facing perspective from Node.js v0.10.34
to io.js v1.0.0.

Renamed file to CHANGELOG.md from ChangeLog.md

Fixes: nodejs#339
@rvagg
Copy link
Member Author

rvagg commented Jan 14, 2015

landed in 16f7fa7 and 63dbcb3

@rvagg rvagg closed this Jan 14, 2015
RafaelGSS pushed a commit that referenced this pull request Sep 23, 2022
Commit dae283d from August 2020 introduced a call to EntropySource()
in SecretKeyGenTraits::DoKeyGen() in src/crypto/crypto_keygen.cc. There
are two problems with that:

1. It does not check the return value, it assumes EntropySource() always
   succeeds, but it can (and sometimes will) fail.

2. The random data returned byEntropySource() may not be
   cryptographically strong and therefore not suitable as keying
   material.

An example is a freshly booted system or a system without /dev/random or
getrandom(2).

EntropySource() calls out to openssl's RAND_poll() and RAND_bytes() in a
best-effort attempt to obtain random data. OpenSSL has a built-in CSPRNG
but that can fail to initialize, in which case it's possible either:

1. No random data gets written to the output buffer, i.e., the output is
   unmodified, or

2. Weak random data is written. It's theoretically possible for the
   output to be fully predictable because the CSPRNG starts from a
   predictable state.

Replace EntropySource() and CheckEntropy() with new function CSPRNG()
that enforces checking of the return value. Abort on startup when the
entropy pool fails to initialize because that makes it too easy to
compromise the security of the process.

Refs: https://hackerone.com/bugs?report_id=1690000
Refs: #35093

Reviewed-By: Rafael Gonzaga <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
PR-URL: #346
Backport-PR-URL: #351
CVE-ID: CVE-2022-35255
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants