| Age | Commit message (Collapse) | Author |
|---|
|
The use case is not cryptographical but we want to compare Erlang
implementation to c implementation so use crypto:strong_rand_bytes anyway.
|
|
Use case in compile.erl is cryptographical so use
crypto:strong_rand_bytes/1 instead.
Use case in test suite is not cryptographical so use
other test instead.
|
|
ssh use cases are cryptographical so use crypto:strong_rand_bytes/1 instead.
|
|
public_key use cases are cryptographical so use
crypto:strong_rand_bytes/1 instead.
|
|
ssl already used crypto:strong_rand_bytes/1 for most operations as
its use cases are mostly cryptographical. Now crypto:strong_rand_bytes/1
will be used everywhere.
However crypto:rand_bytes/1 was used as fallback if
crypto:strong_rand_bytes/1 throws low_entropy, this
will no longer be the case. This is a potential incompatibility.
The fallback was introduced a long time ago for interoperability reasons.
Now days this should not be a problem, and if it is, the security
compromise is not acceptable anyway.
|
|
OpenSSL has deprecated the function RAND_pseudo_bytes used by
crypto:rand_bytes/1, so this function is now deprecated in OTP too.
rand_bytes/3 also used this function, but was not documented
so we can remove it right away.
This commit also removes the fallback in generate_key to use
rand_bytes/1 if strong_rand_bytes/1 throws low entropy.
This is a potential incompatibility but we think it is desirable
as crypto should provide cryptographically secure functions.
|
|
* bjorn/compiler/remove-timestamps/OTP-13504:
Remove timestamps from BEAM files
|
|
As long as anyone can remember, the compilation time has been included
in BEAM files (and can be retrieved using Mod:module_info(compile)).
The timestamp has caused problems for anyone using tools such as 'cmp'
to compare BEAM files or for package managers:
http://erlang.org/pipermail/erlang-questions/2016-April/088717.html
Rarely has the timestamp been of any use. Yes, sometimes the timestamp
could help to figuring out which version of a module was used, but
nowadays a better way is to use Mod:module_info(md5).
To get rid of this problem, remove the timestamp from BEAM files in
OTP 19. Don't add an option to include timestamps.
Utilities that depend on the timestamp will need to be modified.
For example:
http://erlang.org/pipermail/erlang-questions/2016-April/088730.html
Instead of using the compilation time, the MD5 for the BEAM code can
be used. Example:
1> c:module_info(md5).
<<79,26,188,243,168,60,58,45,34,69,19,222,138,190,214,118>>
2> beam_lib:md5(code:which(c)).
{ok,{c,<<79,26,188,243,168,60,58,45,34,69,19,222,138,190,214,118>>}}
3>
|
|
* bjorn/compiler/core-erlang-fixes:
Add compile_SUITE:core_roundtrip/1
v3_core: Construct {badmap,Map} as literal if possible
core_pp: Print {file,File} annotations more compactly
core_pp: Add format_all/1 that prints all annotations
core_parse: Don't sort map patterns
core_parse: Handle annotations in more contexts
cerl_trees: Correct handling of maps in label/2
cerl: Add missing API function is_c_map_pattern/1
|
|
Windows 8 and later have stronger admin checks which requires
erlang to run in privileged shells, ignore for now.
|
|
|
|
and increase some timeouts for very slow machines (arm)
|
|
Needed functionality, to avoid abusing opauqe objects.
|
|
and avoid large logs when tests succed
|
|
Commands could be executed twice, if the command was dispatched
from a callback and caused a recursive invocation of command loop.
Solution is to mark op as -1 before calling wxWidgets.
Also commands could be missed when idle processing was done inside
while executing a recursive callback, solved be always resetting peak
index after idle processing is done.
|
|
|
|
When debugging, it is important that we can trust the Core Erlang
pretty printer and Core Erlang parser.
|
|
|
|
This will speed up test cases that print all annotations.
|
|
|
|
If we pretty print to a file and read it back in, we expect to
get the same cerl data structures back.
|
|
Annotations would not be accepted for all constructs.
|
|
Make sure that we don't convert a map pattern to a map expression.
|
|
Dialyzer would warn about uses of the ?assert(BoolExpr) macro in assert.hrl
if the argument was known to be boolean-only.
|
|
|
|
|
|
|
|
* bjorn/debugger/cuddle-with-tests:
Remove ?line macros
Replace "%" with "%%" at the beginning of a line
Eliminate doc and suite clauses
Eliminate use of the ?t macro
Eliminate use of test_server:format()
Eliminate use of test_server:fail/{0,1}
Use proplists:get_value/2 instead of ?config()
Modernize use of timetraps
int_SUITE: Fix interpretable/1 in a non-installed system
int_SUITE: Fix interpretable/1 on cross-compiled platforms
|
|
|
|
|
|
|
|
* bjorn/compiler/misc-opt:
v3_kernel: Construct literal lists properly
Use the register map in %live in beam_utils:is_killed_block/2
Teach beam_utils to check liveness for put_map instructions
beam_peep: Help out beam_jump
|
|
While we are it, also re-ident the files.
|
|
We want to re-ident the source files after having taken out
all ?line macros. When re-indenting using Emacs, it's important
that comments that should be at the beginning of a line (or
follow the indentation of statements around it) must start with
"%%".
|
|
|
|
|
|
|
|
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
interpretable/1 tests (among other things) that we are not allowed
to interpret modules in certain applications (such as kernel and
stdlib).
int:interpretable/1 as currently implement enforces the restriction
only in an installed system (the applications must have versions,
such as kernel-1.2.3).
We could modify int:interpretable/1 to enforce the restriction,
but it could sometimes be useful to be able to debug (for example)
erl_lint or other library modules that can safely be reloaded
without crashing the run-time system.
Therefore, assume that anyone working in a non-installed system
knows what they are doing and fix the test case so that it stop
failing in a non-installed system.
|
|
c7e82c6b406b teached the debugger to use the 'source' key
in Mod:module_info/1 to help locate the source code
corresponding to a BEAM file. The new test that was added
at the same time will fail if the test suites were
cross-compiled on another computer (i.e., the 'source' key
would not point to the source file on the target computer).
Avoid the problem by letting int_SUITE:init_per_suite/1 compile
the BEAM files. That will ensure that 'source' keys points to
the actual source file.
|
|
OTP-13501
|
|
OTP-13500
|
|
OTP-13502
|
|
|
|
|
|
OTP-13499
|
|
OTP-13500
|
|
OTP-13500
|
