| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
|/
|
|
| |
Because tests good.
|
|
|
|
|
|
| |
Words, sometimes I wonder how they even work
Maybe I missed something.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
These should generally be safe to just ignore, which should be the
default behavior of Expat and LuaExpat
|
|
|
|
|
|
| |
Fixes that a multi-line string ended up "like\
\9this" instead of "like\nthis" as can be demonstrated by somehow
initiating a connection to a HTTP server.
|
|
|
|
| |
A boolean false should blow up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Yes. This is as bad as it sounds. CVE pending.
In Prosody itself, this only affects mod_websocket, which uses util.xml
to parse the <open/> frame, thus allowing unauthenticated remote DoS
using Billion Laughs. However, third-party modules using util.xml may
also be affected by this.
This commit installs handlers which disallow the use of doctype
declarations and processing instructions without any escape hatch. It,
by default, also introduces such a handler for comments, however, there
is a way to enable comments nontheless.
This is because util.xml is used to parse human-facing data, where
comments are generally a desirable feature, and also because comments
are generally harmless.
|
|
|
|
|
| |
Previously this would end up passing the "max" directly to the
underlying storage.
|
|
|
|
| |
This method is a bit complex so good to have some test coverage
|
| |
|
| |
|
|
|
|
| |
Allows reuse of repetitive definitions in schemas.
|
| |
|