| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The use of the error helpers creates an `<error/>` child element
containing the error condition. This is however not allowed as per
XEP-0198, which specifies that the error condition is to be a direct
child of the `<failed/>` stream management element.
This has triggered a fun reconnect loop in aioxmpp where it was
reported by a user [1].
[1]: https://github.com/horazont/aioxmpp/issues/382
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Found this number in a hat.
Sleepy time. Good night.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This fixes the signature parsing and building to work correctly. Sometimes
a signature was one or two bytes too short, and needed to be padded. OpenSSL
can do this for us.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
New behaviour (muc_room_allow_persistent = true, the default):
- Parent host users are not restricted by default (prosody:user)
- Users without roles (by default that is non-admins, non-parent-host users,
and users on other servers) can no longer configure persistence by default.
muc_room_allow_persistent = false will restrict persistence to prosody:admin.
Parent-host users should not be restricted by default, and this can be
configured via the new roles/permissions options.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
change)
With this change and 427dd01f0864, room creation is now effectively restricted
to parent-host users by default. This is a better default than previous
Prosody versions (where room creation was not restricted).
The "local" option for restrict_room_creation is no longer used (any value
other than true/false won't change the default behaviour).
restrict_room_creation = true will grant prosody:admin the ability to create
rooms.
restrict_room_creation = false disables all permission checks.
Anything between these two can be achieved using custom roles and permissions.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
'host_user_role' is the default role of users who have JIDs on the "parent"
host (i.e. jabber.org users on conference.jabber.org). Defaults to
'prosody:user'.
'server_user_roles' is the default role of users who have JIDs on any active
host on the current Prosody instance. Default to nil (no role).
This finally allows better permissions splitting between host and server
users, which has previously been done (e.g. in MUC) with options like
'restrict_room_creation' and 'muc_room_allow_persistent'. Using roles makes
these permissions a lot more flexible, and easier for developers to integrate.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Non-admins don't have a role on MUC services by default. Not even
prosody:user. This meant they had no :create-persistent-room permission, even
if muc_room_allow_persistent was true (the default).
Now we only check the role permissions if persistent room creation is
restricted, otherwise we skip any permission checks, just like previous
versions.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This can happen to sessions before they are assigned a role
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
muppeth)
Fixes
Error in SQL transaction: Error executing statement parameters: ERROR: invalid input syntax for integer
This was handled for INSERT in 9524bb7f3944 but not SELECT.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It's now possible to bind during SASL2 negotiation.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Fixes a test failure on Lua 5.4 where ipairs("") does not produce an
error.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
In Lua 5.3 LUAL_BUFFERSIZE is a macro computed from sizeof and is thus
not known at pre-processing time, so this does not work.
Since Lua 5.1 is no longer supported, we can use luaL_prepbuffsize()
which is available from Lua 5.2
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Removes assumption that LUAL_BUFFERSIZE is known at pre-processing time,
which it is not in Lua 5.3 and 5.4, where it is a computed macro based
on sizeof.
Allocation of stack space is safer and faster, no need to worry about
luaL_prepbuffer failing to allocate memory and skipping free()
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Some changes/improvements in this commit:
- Default token lifetime is now 3600s (from 300s)
- Tokens are only validated once per upload
- "iat"/"exp" are handled automatically by util.jwt
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
To avoid every user of the library needing to add and verify expiry info, this
is now handled by util.jwt itself (if not overridden or disabled).
Issuing tokens that are valid forever is bad practice and rarely desired, and
the default token lifetime is now 3600s (1 hour).
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Except 'none'. Not implementing that one.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Now we can consistently apply the same tests to every algorithm, instead of
duplicating code.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
These are used by the RS*** and PS*** family of JOSE algorithms (e.g. in JWTs)
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
PASETO provides an alternative to JWT with the promise of fewer implementation
pitfalls. The v4.public algorithm allows asymmetric cryptographically-verified
token issuance and validation.
In summary, such tokens can be issued by one party and securely verified by
any other party independently using the public key of the issuer. This has a
number of potential applications in a decentralized network and ecosystem such
as XMPP. For example, such tokens could be combined with XEP-0317 to allow
hats to be verified even in the context of a third-party MUC service.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Specifically, ED25519 key generation/import/export, sign/verify operations,
and AES encrypt/decrypt.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The macros in this header allow creation of GC-managed objects from manually-
managed C alloc/free APIs.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
...with opportunistic writes enabled.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The condition checked for s2sin but not s2sout, so would have ignored
bidi-enabled s2sout sessions. Components as well.
|
| | | | | | | | |
|