Support blind key rotation #399

Слито
Plume_migration_agent слито 3 коммит(ов) из blind-key-rotation в master 5 лет назад
trinity-1686a прокомментировал(а) 5 лет назад
Владелец

Fix #398

  • try to fetch user when receiving an invalid signature
  • regenerate new key-pair when sending Delete activity
Fix #398 - [x] try to fetch user when receiving an invalid signature - [x] regenerate new key-pair when sending `Delete` activity
codecov[bot] прокомментировал(а) 5 лет назад (Перенесено из github.com)

Codecov Report

Merging #399 into master will increase coverage by 0.21%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #399      +/-   ##
==========================================
+ Coverage   27.87%   28.08%   +0.21%     
==========================================
  Files          63       63              
  Lines        7254     7405     +151     
==========================================
+ Hits         2022     2080      +58     
- Misses       5232     5325      +93
# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/399?src=pr&el=h1) Report > Merging [#399](https://codecov.io/gh/Plume-org/Plume/pull/399?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/3128e6a3b9963bda81f482e972eb853c0d564d35?src=pr&el=desc) will **increase** coverage by `0.21%`. > The diff coverage is `0%`. ```diff @@ Coverage Diff @@ ## master #399 +/- ## ========================================== + Coverage 27.87% 28.08% +0.21% ========================================== Files 63 63 Lines 7254 7405 +151 ========================================== + Hits 2022 2080 +58 - Misses 5232 5325 +93 ```
igalic (Перенесено из github.com) рассмотрел(а) изменения 5 лет назад
igalic (Перенесено из github.com) оставил комментарий

👀

👀
igalic (Перенесено из github.com) прокомментировал(а) 5 лет назад

should we be printing stuff here?

should we be printing stuff here?
trinity-1686a рассмотрел(а) изменения 5 лет назад
trinity-1686a прокомментировал(а) 5 лет назад
Автор
Владелец

I kept it because it was here before. If we had a proper logger this should get logged as this could be a an attack trial, but as it is, lost in stdout, I guess it's more of a debugging print?

I kept it because it was here before. If we had a proper logger this should get logged as this could be a an attack trial, but as it is, lost in stdout, I guess it's more of a debugging print?
igalic (Перенесено из github.com) рассмотрел(а) изменения 5 лет назад
igalic (Перенесено из github.com) прокомментировал(а) 5 лет назад

i was wondering where our (debugging) log was

i was wondering where our (debugging) log was
elegaanz (Перенесено из github.com) рассмотрел(а) изменения 5 лет назад
elegaanz (Перенесено из github.com) оставил комментарий

The code looks right, but I think I found a bug (maybe it's only me). To reproduce:

  • Create a@plume.one and b@plume.two
  • Make them follow each other
  • a@plume.one posts two articles, they are received on plume.two as they should
  • a@plume.one deletes one of these articles, and it is deleted on plume.two too
  • a@plume.one waits more than 10 minutes, and delete the second article
  • the Delete activity gets rejected by plume.two

Edit: also note that the next activities from a@plume.one are correctly received by plume.two

The code looks right, but I think I found a bug (maybe it's only me). To reproduce: - Create a@plume.one and b@plume.two - Make them follow each other - a@plume.one posts two articles, they are received on plume.two as they should - a@plume.one deletes one of these articles, and it is deleted on plume.two too - a@plume.one waits more than 10 minutes, and delete the second article - the `Delete` activity gets rejected by plume.two Edit: also note that the next activities from a@plume.one are correctly received by plume.two
elegaanz (Перенесено из github.com) одобрил(а) эти изменения 5 лет назад
elegaanz (Перенесено из github.com) оставил комментарий

It is working now. 👍 (but I don't understand what was wrong with the previous condition, and this one doesn't make sense for me)

It is working now. :+1: (but I don't understand what was wrong with the previous condition, and this one doesn't make sense for me)
trinity-1686a прокомментировал(а) 5 лет назад
Автор
Владелец

previously, the first if would match in case of invalid request, and the second would do exactly the same, match on invalid request. But the first block is the Ok(()) one, so on invalid request it would say "ok this is fine".
Now the condition for the second if is inverted, so when the request is valid it returns Ok(()), when the request is invalid it returns the signature error

previously, the first `if` would match in case of invalid request, and the second would do exactly the same, match on invalid request. But the first block is the Ok(()) one, so on _invalid_ request it would say "ok this is fine". Now the condition for the second `if` is inverted, so when the request is _valid_ it returns Ok(()), when the request is invalid it returns the signature error

Рецензенты

Запрос на слияние был объединен как c4a4ea5b6c.
Вы также можете просмотреть инструкции командной строки.

Шаг 1:

В репозитории вашего проекта посмотрите новую ветку и протестируйте изменения.
git checkout -b blind-key-rotation master
git pull origin blind-key-rotation

Шаг 2:

Объединить изменения и обновить на Forgejo.
git checkout master
git merge --no-ff blind-key-rotation
git push origin master
Войдите, чтобы присоединиться к обсуждению.
Нет рецензентов
Нет этапа
Нет назначенных лиц
2 участников
Уведомления
Срок выполнения
Срок действия недействителен или находится за пределами допустимого диапазона. Пожалуйста, используйте формат 'гггг-мм-дд'.

Срок выполнения не установлен.

Зависимости

Зависимостей нет.

Reference: Plume/Plume#399
Загрузка…
Пока нет содержимого.