| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Result of mutation testing
Remaining mutants are mostly relating to the math.type() fallback.
Another case being that array[#array+1] == array[#array+2] and thus
doesn't matter.
|
|
|
|
| |
Found via mutation testing.
|
| |
|
|
|
|
| |
(98% mutant score, single remaining mutant is a string.sub equivalent)
|
|
|
|
| |
Found via mutation testing.
|
|\ |
|
| |
| |
| |
| | |
Also touching on how arrays are indistinguishable from tables in Lua
|
| |
| |
| |
| | |
Full-URI references are not implemented
|
| |
| |
| |
| | |
Piped trough `sort -g`
|
| |
| |
| |
| | |
You guessed it, mutation testing.
|
| | |
|
| |
| |
| |
| | |
Found via mutation testing.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lines don't appear to do anything useful, and all tests pass when they
are removed. Discovered via mutation testing.
I added extra tests to exercise this code, because I wasn't certain that there
were no side-effects caused by removal. Everything appears to be fine, thanks
to the "pending" check at the start of promise_settle().
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Found this number in a hat.
Sleepy time. Good night.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PASETO spec recommends - no, *requires* - that implementations enforce
type safety for keys, and e.g. do not pass them around as arbitrary byte
strings. Typed wrapper objects are recommended.
I originally followed this advice when starting the lib. However, key wrapping
and type safety is now also a feature of util.crypto. All we're doing is
duplicating it unnecessarily with this additional wrapper code.
|
| |
| |
| |
| |
| | |
Unfortunately there are only a few relevant ones, but they did help catch some
bugs.
|
| |
| |
| |
| | |
Except 'none'. Not implementing that one.
|
| | |
|
| |
| |
| |
| |
| | |
Now we can consistently apply the same tests to every algorithm, instead of
duplicating code.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In many cases code will be either signing or verifying. With asymmetric
algorithms it's clearer and more efficient to just state that once, instead of
passing keys (and possibly other parameters) with every sign/verify call.
This also allows earlier validation of the key used.
The previous (HS256-only) sign/verify methods continue to be exposed for
backwards-compatibility.
|
| |
| |
| |
| |
| | |
Specifically, ED25519 key generation/import/export, sign/verify operations,
and AES encrypt/decrypt.
|
| |
| |
| |
| |
| | |
Some fiddling is required now in error_reply() to ensure the cursor is in the
same place as before this change (a lot of code apparently uses that feature).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes you only care about a single attribute, but the child tag
itself may be optional, leading to needing `tag and tag.attr.foo` or
`stanza:find("tag@foo")`.
The `:find()` method is fairly complex, so avoiding it for this kind of
simpler use case is a win.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Changes sub-second part of example timestamp to .5 in order to avoid
floating point issues.
Some clients use timestamps when ordering messages which can lead to
messages having the same timestamp ending up in the wrong order.
It would be better to preserve the order messages are sent in, which is
the order they were stored in.
|
| |
| |
| |
| |
| |
| | |
Lua since 5.3 raises a fuss when time functions are handed a number with
a fractional part and the underlying C functions are all based on
integer seconds without support for more precision.
|
| |
| |
| |
| | |
The expected value goes first.
|
| |
| |
| |
| |
| |
| | |
See https://www.ietf.org/blog/finalizing-ietf-tools-transition/
Already done in various other places.
|
|\| |
|
| |
| |
| |
| |
| | |
Passes with memory, internal, sqlite
Fails with postgres as in #1766
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is happens if the account is new and doesn't have any bookmarks
yet, which is not a problem.
Rarely seen since most clients currently use the older version of
XEP-0084 stored in XEP-0049 rather than in PEP, but at least one
(Converse.js )does.
One scenario in which this would show up often is with Converse.js as a
guest chat using anonymous authentication, where all "accounts" would
always be new and not have any bookmarks. This scenario probably does
not need to have mod_bookmarks at all, but if enabled globally it would
likely become loaded onto the VirtualHost unless explicitly disabled.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The JSON Schema specification says that schemas are objects or booleans,
and that the 'type' property is optional and can be an array.
This module previously allowed bare type names as schemas and did not
really handle booleans.
It now handles missing 'type' properties and boolean 'true' as a schema.
Objects and arrays are guessed based on the presence of 'properties' or
'items' field.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MattJ reported a curious issue where validation did not work as
expected. Primarily that the "type" field was expected to be mandatory,
and thus leaving it out would result in no checks being performed.
This was likely caused by misreading during initial development.
Spent some time testing against
https://github.com/json-schema-org/JSON-Schema-Test-Suite.git and
discovered a multitude of issues, far too many to bother splitting into
separate commits.
More than half of them fail. Many because of features not implemented,
which have been marked NYI. For example, some require deep comparisons
e.g. when objects or arrays are present in enums fields.
Some because of quirks with how Lua differs from JavaScript, e.g. no
distinct array or object types. Tests involving fractional floating
point numbers. We're definitely not going to follow references to remote
resources. Or deal with UTF-16 sillyness. One test asserted that 1.0 is
an integer, where Lua 5.3+ will disagree.
|
| |
| |
| |
| | |
Part of #1600
|
| | |
|
|\| |
|
| |
| |
| |
| | |
Example values from RFC 6901
|
|\| |
|
| |
| |
| |
| |
| |
| | |
The second return value is (not insensibly) assumed to be an error. Instead of
returning a value there in the success case, copy the positional arguments
into the existing opts table.
|
| | |
|
| |
| |
| |
| | |
#NotHappyEyeballs
|