From 9c44cf205f098ef499854bb52b698b594807b5c7 Mon Sep 17 00:00:00 2001 From: Claire Date: Tue, 23 Nov 2021 00:15:31 +0100 Subject: [PATCH 1/4] Add FEDERATION.md (#17029) Some ActivityPub projects have a FEDERATION.md which is used to describe the various extensions they use. Everything here is also documented elsewhere, but it's a concise starting point with links to that documentation. --- FEDERATION.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 FEDERATION.md diff --git a/FEDERATION.md b/FEDERATION.md new file mode 100644 index 0000000000..cd1957cbd1 --- /dev/null +++ b/FEDERATION.md @@ -0,0 +1,30 @@ +## ActivityPub federation in Mastodon + +Mastodon largely follows the ActivityPub server-to-server specification but it makes uses of some non-standard extensions, some of which are required for interacting with Mastodon at all. + +Supported vocabulary: https://docs.joinmastodon.org/spec/activitypub/ + +### Required extensions + +#### Webfinger + +In Mastodon, users are identified by a `username` and `domain` pair (e.g., `Gargron@mastodon.social`). +This is used both for discovery and for unambiguously mentioning users across the fediverse. Furthermore, this is part of Mastodon's database design from its very beginnings. + +As a result, Mastodon requires that each ActivityPub actor uniquely maps back to an `acct:` URI that can be resolved via WebFinger. + +More information and examples are available at: https://docs.joinmastodon.org/spec/webfinger/ + +#### HTTP Signatures + +In order to authenticate activities, Mastodon relies on HTTP Signatures, signing every `POST` and `GET` request to other ActivityPub implementations on behalf of the user authoring an activity (for `POST` requests) or an actor representing the Mastodon server itself (for most `GET` requests). + +Mastodon requires all `POST` requests to be signed, and MAY require `GET` requests to be signed, depending on the configuration of the Mastodon server. + +More information on HTTP Signatures, as well as examples, can be found here: https://docs.joinmastodon.org/spec/security/#http + +### Optional extensions + +- Linked-Data Signatures: https://docs.joinmastodon.org/spec/security/#ld +- Bearcaps: https://docs.joinmastodon.org/spec/bearcaps/ +- Followers collection synchronization: https://git.activitypub.dev/ActivityPubDev/Fediverse-Enhancement-Proposals/src/branch/main/feps/fep-8fcf.md From 02a87431cf260e466ff58cc159b52cbce9aaef6b Mon Sep 17 00:00:00 2001 From: Claire Date: Wed, 24 Nov 2021 17:41:03 +0100 Subject: [PATCH 2/4] Fix error when suspending user with an already-existing canonical email block (#17036) * Fix error when suspending user with an already-existing canonical email block Fixes #17033 While attempting to create a `CanonicalEmailBlock` with an existing hash would raise an `ActiveRecord::RecordNotUnique` error, this being done within a transaction would cancel the whole transaction. For this reason, checking for uniqueness in Rails would query the database within the transaction and avoid invalidating the whole transaction for this reason. A race condition is still possible, where multiple accounts sharing a canonical email would be blocked in concurrent transactions, in which only one would succeed, but that is way less likely to happen that the current issue, and can always be retried after the first failure, unlike the current situation. * Add tests --- app/models/canonical_email_block.rb | 2 +- spec/models/account_spec.rb | 31 +++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/app/models/canonical_email_block.rb b/app/models/canonical_email_block.rb index a8546d65af..be8c45bfe3 100644 --- a/app/models/canonical_email_block.rb +++ b/app/models/canonical_email_block.rb @@ -15,7 +15,7 @@ class CanonicalEmailBlock < ApplicationRecord belongs_to :reference_account, class_name: 'Account' - validates :canonical_email_hash, presence: true + validates :canonical_email_hash, presence: true, uniqueness: true def email=(email) self.canonical_email_hash = email_to_canonical_email_hash(email) diff --git a/spec/models/account_spec.rb b/spec/models/account_spec.rb index 03d6f5fb0f..65e6714c0e 100644 --- a/spec/models/account_spec.rb +++ b/spec/models/account_spec.rb @@ -5,6 +5,37 @@ RSpec.describe Account, type: :model do let(:bob) { Fabricate(:account, username: 'bob') } subject { Fabricate(:account) } + describe '#suspend!' do + it 'marks the account as suspended' do + subject.suspend! + expect(subject.suspended?).to be true + end + + it 'creates a deletion request' do + subject.suspend! + expect(AccountDeletionRequest.where(account: subject).exists?).to be true + end + + context 'when the account is of a local user' do + let!(:subject) { Fabricate(:account, user: Fabricate(:user, email: 'foo+bar@domain.org')) } + + it 'creates a canonical domain block' do + subject.suspend! + expect(CanonicalEmailBlock.block?(subject.user_email)).to be true + end + + context 'when a canonical domain block already exists for that email' do + before do + Fabricate(:canonical_email_block, email: subject.user_email) + end + + it 'does not raise an error' do + expect { subject.suspend! }.not_to raise_error + end + end + end + end + describe '#follow!' do it 'creates a follow' do follow = subject.follow!(bob) From 08a7c5139d34050061b17d9ea562ab29aec81a45 Mon Sep 17 00:00:00 2001 From: trwnh Date: Wed, 24 Nov 2021 13:24:09 -0600 Subject: [PATCH 3/4] Better ordering for bug report issue template (#17019) Logically, it makes more sense to provide the steps leading up to the bug before asking what the bug is. This change moves "steps to reproduce" above "expected behavior" and "actual behavior" to enforce the above progression and logical flow. --- .github/ISSUE_TEMPLATE/1.bug_report.yml | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/1.bug_report.yml b/.github/ISSUE_TEMPLATE/1.bug_report.yml index 4f420416b5..9cdf813f7b 100644 --- a/.github/ISSUE_TEMPLATE/1.bug_report.yml +++ b/.github/ISSUE_TEMPLATE/1.bug_report.yml @@ -8,6 +8,17 @@ body: Make sure that you are submitting a new bug that was not previously reported or already fixed. Please use a concise and distinct title for the issue. + - type: textarea + attributes: + label: Steps to reproduce the problem + description: What were you trying to do? + value: | + 1. + 2. + 3. + ... + validations: + required: true - type: input attributes: label: Expected behaviour @@ -20,17 +31,6 @@ body: description: What happened? validations: required: true - - type: textarea - attributes: - label: Steps to reproduce the problem - description: What were you trying to do? - value: | - 1. - 2. - 3. - ... - validations: - required: true - type: textarea attributes: label: Specifications From 46e62fc4b33f3566eb9bf588b15bac28cae967a3 Mon Sep 17 00:00:00 2001 From: zunda Date: Wed, 24 Nov 2021 19:29:05 +0000 Subject: [PATCH 4/4] Upgrade Ruby to 3.0.3 (#17038) https://www.ruby-lang.org/en/news/2021/11/24/ruby-3-0-3-released/ --- .ruby-version | 2 +- Dockerfile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.ruby-version b/.ruby-version index b502146930..75a22a26ac 100644 --- a/.ruby-version +++ b/.ruby-version @@ -1 +1 @@ -3.0.2 +3.0.3 diff --git a/Dockerfile b/Dockerfile index f5de242104..309ec06f4d 100644 --- a/Dockerfile +++ b/Dockerfile @@ -27,7 +27,7 @@ RUN ARCH= && \ mv node-v$NODE_VER-linux-$ARCH /opt/node # Install Ruby 3.0 -ENV RUBY_VER="3.0.2" +ENV RUBY_VER="3.0.3" RUN apt-get update && \ apt-get install -y --no-install-recommends build-essential \ bison libyaml-dev libgdbm-dev libreadline-dev libjemalloc-dev \