| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is only a draft extension, but it is quite stable and already supported
by some implementations. OpenSSH has had it for some year now.
|
|
Change the handling of option pref_public_key_algs so that the same
checks are not performed twice.
|
|
|
|
* raimo/rand-dev/OTP-14295:
Polish
|
|
|
|
|
|
* sverker/refactor:
erts: Introduce struct binary_internals
erts: Introduce erts_bin_release
erts: Init refc=1 in erts_bin_drv_alloc*
erts: Init refc=1 in erts_bin_nrml_alloc
erts: Remove deliberate leak of hipe fun entries
erts: Remove hipe_bifs:remove_refs_from/1
Refactor hipe specific code to use ErtsCodeInfo
erts: Refactor ErtsCodeInfo.native
|
|
* ingela/available_hash_signature_algs/OTP-13820:
ssl: TLS-1.2 clients will now always send hello messages on its own format.
|
|
Drop some legacy Emacs compatibility code
|
|
|
|
* lukas/erts/list_to_port/OTP-14348:
erts: Add erlang:list_to_port/1 debug bif
erts: Auto-import port_to_list for consistency
erts: Polish off erlang:list_to_ref/1
|
|
|
|
Follow the same pattern as pid_to_list
|
|
* maint:
stdlib: Fix documentation on sets’ representation
|
|
* lukas/erts/deprecate-non-smp/OTP-14272:
erts: Fix testcases for smp +S 1:1
erts: Deprecate the non-smp emulators
|
|
erl_mseg.c: don't use invalid indices in - > cache_powered_node[]
OTP-14360
|
|
The Erlang shell's temporary support for Unicode node names is
removed. There will be no support for Unicode node names in
Erlang/OTP 20.0.
|
|
stdlib: Fix documentation on sets’ representation
|
|
* siri/sysdoc/design_princ/fix-xmllint-error:
Fix xmllint warning in Design Principles/Supervisor Behaviour
|
|
* siri/ct/delete-old-logs/OTP-14179:
[ct] Add 'keep_logs' option
|
|
|
|
* dgud/stdlib/unicode-string/OTP-10289:
Handle chardata in string:to_float and string:to_list
New unicode aware string module that works with unicode:chardata()
Add nf(k)d, nf(k)c conversion functions to unicode module
Reorder code and whitespace fixes
Add unicode_util
|
|
|
|
Works with unicode:chardata() as input as was decided on OTP board
meeting as response to EEP-35 a long time ago.
Works on graphemes clusters as base, with a few exceptions, does not
handle classic (nor nfd'ified) Hangul nor the extended grapheme
clusters such as the prepend class. That would make handling binaries
as input/output very slow.
List input => list output, binary input => binary output and
mixed input => mixed output for all find/split functions.
So that results can be post-processed without the need to invoke
unicode:characters_to_list|binary for intermediate data.
pad functions return lists of unicode:chardata() for performance.
|
|
|
|
Put internal functions below api functions.
|
|
A base for unicode functions, not intended to be a user api.
Whitespace returns a reasonable subset of non nobreak whitespace
characters.
Implementation notes:
Make function clauses instead of using arrays and store tuples instead
of maps to save space.
|
|
* maint:
Updated OTP version
Prepare release
Do not ignore SIGTERM when VM has been started with +Bi
Conflicts:
OTP_VERSION
erts/emulator/sys/unix/sys.c
erts/vsn.mk
|
|
* maint-19:
Updated OTP version
Prepare release
Do not ignore SIGTERM when VM has been started with +Bi
|
|
* zandra/stdlib/optional-callbacks/OTP-13801:
wx: make wx_object callbacks optional
stdlib: Make gen_fsm callbacks optional
stdlib: Make gen_event callbacks optional
stdlib: Make gen_server callbacks optional
|
|
Merge branch RoadRunnr/feature/so_bindtodevice (GitHub#1326) into master
OTP-14357
|
|
* lukas/erts/fix_non-smp_scheduler_data_init/OTP-14152:
erts: Initialize esdp->type in non-smp to normal
|
|
Make beam_validator track type formation for binary operations
|
|
Fixes https://bugs.erlang.org/browse/ERL-406 - a bug introduced in
0377592dc2238f561291be854d2ce859dd9a5fb1
|
|
|
|
|
|
* rickard/sigterm/OTP-14358:
Do not ignore SIGTERM when VM has been started with +Bi
|
|
|
|
OTP-14356
* rickard/timer-improvements:
Fix of later timer wheel
Minimum timeout position in each timer wheel
Manage timers to trigger at once in a slot similar to other timers
Introduce timer slot range counters
Timer wheel divided into a "soon wheel" and a "later wheel"
Remove unnecessary cancel callback from timer-wheel timers
Rearrange timer struct fields in order to simplify
Use timer wheel for short BIF timers
Use magic refs for BIF timers
Remove accessor BIF timer implementation
Fix aux-work timer implementation
|
|
* rand/arbitrary_normal_distributions:
rand: Support arbitrary normal distributions
Conflicts:
lib/stdlib/test/rand_SUITE.erl
|
|
|
|
|
|
|
|
|
|
|
|
Note this is a change form how it works for earlier versions that will
send the first hello message on the lowest supported version.
From RFC 5246
Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server.
A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is
willing to use) only versions greater than client_version, it MUST
send a "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
|
|
|
|
|
