diff --git a/README.md b/README.md index f8e6bb423..35cd805d9 100644 --- a/README.md +++ b/README.md @@ -373,7 +373,7 @@ See `READMEs/README.detailed-latency.md` for how to use it. ## Client connection logic rewrite -Lws master now makes much better use of the DNS results for ipv4 and ipv6... it +Lws now makes much better use of the DNS results for ipv4 and ipv6... it will iterate through them automatically making the best use it can of what's provided and attempting new connections for each potentially usable one in turn before giving up on the whole client connection attempt. @@ -405,7 +405,7 @@ H1 is not so simple to parse because the header length is not known until it has been fully parsed. The next header, or http body may be directly coalesced with the header as well. Lws has supported bulk h1 parsing from a buffer for a long time, but on clientside due to interactions with http proxying it had -been stuck parsing the header bytewise out of the tls buffer. In master, +been stuck parsing the header bytewise out of the tls buffer. Now, everything now bulk parses from a buffer and uses a buflist to pass leftovers through the event loop cleanly. @@ -423,7 +423,7 @@ schedule your own arbitrary callbacks using this system. ## Master is now MIT-licensed -Libwebsockets master is now under the MIT license. See ./LICENSE. +Libwebsockets is now under the MIT license. See ./LICENSE. ## Support @@ -440,5 +440,5 @@ You can get the latest version of the library from git: - https://libwebsockets.org/git -Doxygen API docs for master: https://libwebsockets.org/lws-api-doc-master/html/index.html +Doxygen API docs for development: https://libwebsockets.org/lws-api-doc-master/html/index.html diff --git a/READMEs/README.content-security-policy.md b/READMEs/README.content-security-policy.md index 0fe0cc209..462adce23 100644 --- a/READMEs/README.content-security-policy.md +++ b/READMEs/README.content-security-policy.md @@ -17,7 +17,7 @@ CSP lets the origin server define what is legitimate for the page it served and everything else is denied. The CSP for warmcat.com and libwebsockets.org looks like this, -I removed a handful of whitelisted image sources like travis +I removed a handful of approved image sources like travis status etc for clarity... ``` @@ -40,7 +40,7 @@ provide a very significant increase in client security. ### Implications of strict CSP Halfhearted CSP isn't worth much. The only useful approach is to start -with `default-src 'none'` which disables everything, and then whitelist the +with `default-src 'none'` which disables everything, and then allow the minimum needed for the pages to operate. "Minimum needed for the pages to operate" doesn't mean defeat the protections @@ -63,7 +63,7 @@ files referenced in the document `` section, along these lines: #### Inline styles must die All styling must go in one or more `.css` file(s) best served by the same -server... while you can whitelist other sources in the CSP if you have to, +server... while you can approve other sources in the CSP if you have to, unless you control that server as well, you are allowing whoever gains access to that server access to your users. diff --git a/READMEs/README.release-policy.md b/READMEs/README.release-policy.md index c6ddee866..4fc4cb345 100644 --- a/READMEs/README.release-policy.md +++ b/READMEs/README.release-policy.md @@ -9,9 +9,9 @@ nobody dare think about updating it. The stable releases go on to a branch like v4.0-stable as described below, over time these attract dozens or even hundreds of minor or major fix patches -backported from master. So you should not consume tags like v4.0.0 but build -into your planning that you will need to follow v4.0-stable in order to stay on -top of known bugs. +backported from the development branch. So you should not consume tags like +v4.0.0 but build into your planning that you will need to follow v4.0-stable in +order to stay on top of known bugs. And we only backport fixes to the last stable release, although we will make exceptions for important fixes. So after a while, trying to stick with one @@ -21,13 +21,13 @@ should build into your planning that you will follow lws release upgrades. If you find problems and create fixes, please upstream them, simplifying your life so you can just directly consume the upstream tree with no private changes. -## Master branch +## Development Master branch is the default and all new work happens there. It's unstable and subject to history rewrites, patches moving about and being squashed etc. In terms of it working, it is subject to passing CI tests including a battery of runtime tests, so if it is passing CI as it usually is then it's probably in -usable shape. See "Why no history on master" below for why it's managed like +usable shape. See "Why no history on development" below for why it's managed like that. ![all work happens on master](../doc-assets/lws-relpol-1.svg) @@ -42,10 +42,10 @@ patches there. Instead use a flow like this: $ git fetch https://libwebsockets.org/repo/libwebsockets +master:m && git reset --hard m ``` -This fetches current remote master into local branch `m`, and then forces your +This fetches current remote development branch into local branch `m`, and then forces your local checkout to exactly match `m`. This replaces your checked-out tree including any of your local changes, so stash those first, or use stgit or so -to pop them before updating your basis against lws master. +to pop them before updating your basis against lws development. ## Stable branches @@ -53,23 +53,23 @@ Master is very useful for coordinating development, and integrating WIP, but for distros or integration into large user projects some stability is often more desirable than the latest development work. -Periodically, when master seems in good shape and various new developments seem -to be working, it's copied out into a versioned stable branch, like `v3.0-stable`. +Periodically, when development seems in good shape and various new developments seem +to be working, it's copied out into a versioned stable branch, like `v4.0-stable`. -![stable branches are copied from master](../doc-assets/lws-relpol-2.svg) +![stable branches are copied from development](../doc-assets/lws-relpol-2.svg) -The initial copy is tagged with, eg, `v3.0.0`. +The initial copy is tagged with, eg, `v4.0.0`. -(At that time, master's logical version is set to "...99", eg, `v3.0.99` so -version comparisons show that version of master is "later" than any other -v3.0 version, which will never reach 99 point releases itself, but "earlier" -than, eg, v3.1.) +(At that time, development's logical version is set to "...99", eg, `v4.0.99` so +version comparisons show that development version is "later" than any other +v4.0 version, which will never reach 99 point releases itself, but "earlier" +than, eg, v4.1.) ## Backport policy -Work continues on master, and as part of that usually bugs are reported and / or -fixes found that may apply not just to current master, but the version of master -that was copied to form the last -stable branch. +Development continues, and as part of that usually bugs are reported and / or +fixes found that may apply not just to current development, but the version of +the development branch that was copied to form the last -stable branch. In that case, the patch may be backported to the last stable branch to also fix the bug there. In the case of refactors or major internal improvements, these @@ -108,11 +108,11 @@ uncommon though. ![backport to multiple stable branches](../doc-assets/lws-relpol-5.svg) -## Why no history on master +## Why no history on the development branch Git is a wonderful tool that can be understood to have two main modes of operation, merge and rebase that are mutually exclusive. Most devs only use merge / pull, -but rebase / fetch is much more flexible. Running master via rebases allows me to +but rebase / fetch is much more flexible. Developing via rebases allows me to dispense with feature branches during development and enables tracking multiple in-progress patches in-tree by updating them in place. If this doesn't make sense or seems heretical to you, it's OK I don't need devsplain'ing about it, diff --git a/include/libwebsockets/lws-genec.h b/include/libwebsockets/lws-genec.h index 2cb57b4dc..ee62abe3e 100644 --- a/include/libwebsockets/lws-genec.h +++ b/include/libwebsockets/lws-genec.h @@ -72,7 +72,7 @@ struct lws_ec_curves { * \param context: your lws_context (for RNG access) * \param curve_table: NULL, enabling P-256, P-384 and P-521, or a replacement * struct lws_ec_curves array, terminated by an entry with - * .name = NULL, of curves you want to whitelist + * .name = NULL, of curves you want to allow * * Initializes a genecdh */ @@ -118,7 +118,7 @@ lws_genecdh_compute_shared_secret(struct lws_genec_ctx *ctx, uint8_t *ss, * \param context: your lws_context (for RNG access) * \param curve_table: NULL, enabling P-256, P-384 and P-521, or a replacement * struct lws_ec_curves array, terminated by an entry with - * .name = NULL, of curves you want to whitelist + * .name = NULL, of curves you want to allow * * Initializes a genecdh */ diff --git a/include/libwebsockets/lws-netdev.h b/include/libwebsockets/lws-netdev.h index 163dac97b..8a0dc03f7 100644 --- a/include/libwebsockets/lws-netdev.h +++ b/include/libwebsockets/lws-netdev.h @@ -159,7 +159,7 @@ typedef enum { LWSNDVWIFI_STATE_STAT, /* * trying to connect to another non-group AP. If we don't get an - * IP within a timeout and retries, blacklist it and go back + * IP within a timeout and retries, mark it as unusable it and go back */ LWSNDVWIFI_STATE_STAT_HAPPY, } lws_netdev_wifi_state_t; diff --git a/include/libwebsockets/lws-ssd1306-i2c.h b/include/libwebsockets/lws-ssd1306-i2c.h index 4f757904f..8b2f6e37e 100644 --- a/include/libwebsockets/lws-ssd1306-i2c.h +++ b/include/libwebsockets/lws-ssd1306-i2c.h @@ -26,7 +26,7 @@ #define __LWS_DISPLAY_SSD1306_I2C_H__ /* - * D/C# pin on SSD1306 sets the I2C slave ads + * D/C# pin on SSD1306 sets the I2C device ads * from these two options (7-bit address) */ diff --git a/lib/misc/fts/README.md b/lib/misc/fts/README.md index fcb225cf3..e85fee28c 100644 --- a/lib/misc/fts/README.md +++ b/lib/misc/fts/README.md @@ -112,7 +112,7 @@ more or less bytes according to the value. So the peak memory requirements for large tries are much bigger than the size of the serialized trie file that is output. -For the linux kernel at 4.14 and default indexing whitelist on a 2.8GHz AMD +For the linux kernel at 4.14 and default indexing list on a 2.8GHz AMD threadripper (using one thread), the stats are: Name|Value