Currrently, builds for patches are broken because the version numbers
generated for them are not valid according to PEP 440 [1].
Previous attempts [2] have shown that this cannot be solved in a single
commit (needs coordination with sr.ht-apkbuilds), so here is an attempt
at preparing this repo for a switch without breaking anything.
The grand plan is roughly:
1. Add a pyproject.toml without touching setup.py (this commit)
2. Switch APKBUILD from `python setup.py build` to `python -m build`
3. Reduce setup.py to a stub, encoding all relevant information in
pyproject.toml
With this commit, this module can be build with both `python setup.py
build` and `python -m build`, if, _and only if_ the PKGVER environment
variable is set, which is true for all our tooling.
As the version passed in via the environment is still not
PEP440-compatible, packaging non-tagged versions will remain broken
until step three above is executed.
The .gitattributes and .git_archival files are included for the future
setup. Since packages are built from `git-archive` tarballs, the commit
information has to be transported into the tarballs. The setuptools-scm
package specifies a mechanism for this [3]. Note, that in order to avoid
a hilarious bug [4] the checked in `.git_archival.txt` differs from the
template found in the documentation. The git version on git.sr.ht is new
enough that the `describe-name` will be expanded, and if present it is
the only information that setuptools-scm really requires.
[1] https://peps.python.org/pep-0440
[2] https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/50784
[3]: https://setuptools-scm.readthedocs.io/en/latest/usage/#git-archives
[4]: https://github.com/pypa/setuptools_scm/issues/806
This commit enables spreading the config in /etc/sr.ht - and, crucially,
_only_ in /etc/sr.ht - over multiple .ini files.
As before, if a file ./config.ini is found, it (and only it) is loaded
and any config in /etc is ignored.
Spreading the config over multiple files will make it much easier to
create containerized versions, where e.g. different secrets can be made
available in different files, but rendering it all into one big file
would require some preprocessing.
turns out, i broke the "Review patch" button link (.btn.btn-primary) in
the "this thread contains a patchset" info alert when trying to fix the
legacy OAuth link contrast.
this fixes both the "Review patch" button, and the legacy OAuth link,
and shouldn't break the contrast for any links and buttons in alert
boxes.
contrast for links on danger alert is fixed as well.
partially reverts commit 1dd2f363ce
Mistletoe supports Github's tables extension, including cell alignment
(see [1]). However, the sanitizer currently does not allow the align
attributes on the table cells, so the alignment never renders.
Add the align attribute to the list of allowed attributes for td and th
element, so that cell alignment works as expected.
[1] https://github.github.com/gfm/#example-199
The validation object's error messages are intended for display (i.e.
HTML rendering). To assert that no user-supplied HTML is ever rendered,
escape the error messages as they are passed in.
Thanks to Naglis Jonaitis for the report.
The GraphQL error messages can contain user-supplied input (such as text
input that was deemed invalid). However, the validation object's error
messages are intended for display (i.e. HTML rendering). To assert that
no user-supplied HTML is rendered, escape the GraphQL error messages as
they get copied to the validation object.
Thanks to Naglis Jonaitis for the report.
Now that the sanitizer has become pretty strict, this will be needed for
the root wiki, where sanitization is not a concern, as the content comes
from the admin(s).
This is useful for READMEs and the like -- the tags `sup` and `sub` are
not harmful, and allow for things like footnotes.
Signed-off-by: Julia DeMille <me@jdemille.com>
>From WHATWG Encoding specification section 4.2 "Names and labels" [1]:
Authors must use the UTF-8 encoding and must use its (ASCII
case-insensitive) "utf-8" label to identify it.
Although browsers must accept "utf8" as a charset, "utf-8" is the
standard spelling and should probably be used instead.
[1]: https://encoding.spec.whatwg.org/#names-and-labels
Allowing arbitrary class attributes allows users to style content in
such way (be re-using global CSS classes) that they can escape the
intended target element, causing effects that can be considered suitable
for phishing.
Thanks to Ruben for the responsible disclosure.
This chases a similar report for github posted at
https://101010.pl/@mcc@mastodon.social/110742090990556162
in that "@nabijaczleweli@101010.pl" is autolinked as
"@<mailto:nabijaczleweli@101010.pl>"
which sucks for obvious reasons
(it's not actually a correct mail address,
the actual purpose is muddied by the autolinking).
Instead, match against "@?<previous mail regex>", and eject addresses
that start with @s as raw text.
fixes low contrast link for oauth legacy link in meta.sr.ht/oauth2 and
the confirmation link in user page for user admin.
retroactively applies the same CSS selector to other types of alerts,
hopefully this doesn't break something existing.
It's mostly unused by now. The only small gotcha is that we stop signing
the error email (sent when catching otherwise unhandled exceptions).
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
Fixes the following TypeError:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/flask/app.py", line 2073, in wsgi_app
response = self.full_dispatch_request()
File "/usr/lib/python3.9/site-packages/flask/app.py", line 1518, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/lib/python3.9/site-packages/flask/app.py", line 1516, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/lib/python3.9/site-packages/flask/app.py", line 1502, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
File "/usr/lib/python3.9/site-packages/srht/oauth/decorator.py", line 83, in wrapper
return _internal_auth(f, token[1], *args, **kwargs)
File "/usr/lib/python3.9/site-packages/srht/oauth/decorator.py", line 23, in _internal_auth
auth = verify_encrypted_authorization(auth)
File "/usr/lib/python3.9/site-packages/srht/crypto.py", line 99, in verify_encrypted_authorization
response=json.dumps({
TypeError: unhashable type: 'dict'
The SVG version now switches colors with the browser's theme. An outline
is added to both SVG and PNG versions for browsers that do not support
`prefers-color-scheme` or SVG favicons. The PNG version now has an added
`sizes="any"` attribute to work around Chrome preferring it over SVG.
Fixes the following error:
Traceback (most recent call last):
File "/home/simon/src/meta.sr.ht/./metasrht-initdb", line 10, in <module>
import metasrht.types
File "/home/simon/src/meta.sr.ht/metasrht/types/__init__.py", line 1, in <module>
from .user import *
File "/home/simon/src/meta.sr.ht/metasrht/types/user.py", line 5, in <module>
from srht.oauth import UserMixin, UserType
File "/home/simon/src/core.sr.ht/srht/oauth/__init__.py", line 61, in <module>
from srht.oauth.blueprint import oauth_blueprint
File "/home/simon/src/core.sr.ht/srht/oauth/blueprint.py", line 6, in <module>
from srht.flask import csrf_bypass
File "/home/simon/src/core.sr.ht/srht/flask.py", line 11, in <module>
from srht.markdown import markdown
File "/home/simon/src/core.sr.ht/srht/markdown.py", line 175, in <module>
tags=bleach.sanitizer.ALLOWED_TAGS + [
TypeError: unsupported operand type(s) for +: 'frozenset' and 'list'
Currently, the favicon is served as inline data with every page. This
commit makes it an external resource instead, so it can benefit from
caching. In addition, an SVG version is added, which is not supported by
all browsers [1], but is roughly one tenth of the size. It is the one
displayed in the header on every page, only in white.
[1]: https://caniuse.com/link-icon-svg
This executes a GraphQL operation with the specified OAuth 2.0
token used for authentication.
This will be useful to implement OAuth 2.0 token introspection.
A Flask decorator to enable CORS.
This will be useful to allow browser-based clients to perform
HTTP requests on some endpoints, e.g. to allow gamja to use the
OAuth 2.0 endpoints.
Drew DeVault