idec.talks

\/ . Andrew Lobanov to Anotheroneuser @ Re: Документация 12/03/19 12:07

\/ . Andrew Lobanov to Difrex @ Re: Netmail 12/03/19 12:07

\/ . Difrex to Andrew Lobanov @ Re: Netmail 12/03/19 12:27

\/ . Andrew Lobanov to Difrex @ Re: Netmail 13/03/19 09:34

\/ . vit01 to All @ IDEC Mobile 16/03/19 09:33

\/ . G2I to All @ Re: Netmail 16/03/19 13:43

\/ . G2I to All @ Re: Netmail 16/03/19 13:54

\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 14:10

\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 14:30

\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 15:41

\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 15:56

\/ . vit01 to Difrex @ Re: dynamic 16/03/19 16:20

\/ . G2I to All @ Re: Netmail 16/03/19 19:35

\/ . Difrex to All @ Апгрейд на dynamic 17/03/19 07:42

\/ . Andrew Lobanov to G2I @ Re: Netmail 18/03/19 04:04

G2I> Ведь нам надо сделать так, чтобы
G2I> 1. Нетмейл-сообщения ходили между станциями

Это просто.

G2I> 2. Станция не могла прочитать нетмейл чужих станций

Почему? Если нужно шифрование, то оно должно быть на стороне клиента, а не на стороне ноды.

G2I> 2.1 Но при этом могла отдавать их даунлинкам

Это совсем просто.

G2I> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

Я не умею пользоваться гитхабом, так что напишу свои мысли тут.

1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
3. Шифрование не является частью протокола.

То есть выглядеть оно должно примерно так:

Поинт забирает почту: GET /x/m/<authstr>[/слайс].

Поинт отправляет почту: POST /x/m/ (параметры pauth и tmsg).

Нода забирает почту с аплинка: GET /x/n/<password>.

Этого уже достаточно для рабочей лички, в принципе.

Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.

За основу формата сообщений предлагаю взять существующий формат:

====

ii/ok[/reply/<msgid>]
<адрес получателя>
<время>
<имя отправителя>
<адрес отправителя>
<имя получателя>
<тема>

<тело сообщения>

====

И для отправки тоже:

====

<адрес получателя>
<имя получателя>
<тема>

[@repto:<msgid>]
<тело сообщения>

====

В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?

ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.

qfB7Ip... . ОТВЕТИТЬ

\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 07:20

\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 08:31

\/ . Andrew Lobanov to Difrex @ Re: Netmail 20/03/19 07:42

\/ . vit01 to Andrew Lobanov @ Re: Netmail 20/03/19 08:33

\/ . Andrew Lobanov to vit01 @ Re: Netmail 20/03/19 09:26

\/ . vit01 to Andrew Lobanov @ Re: Netmail 20/03/19 12:45

AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

AL> Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.

Предположим, у нас есть 3 станции по такой схеме:

====

node1 ---- node2 ---- node3

====

node1 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

fRVQwF... . ОТВЕТИТЬ

\/ . Difrex to Andrew Lobanov @ Re: Netmail 20/03/19 14:48

\/ . Difrex to vit01 @ Re: Netmail 20/03/19 14:47

\/ . Difrex to vit01 @ Re: IDEC Mobile 20/03/19 14:49

\/ . Andrew Lobanov to vit01 @ Re: Netmail 21/03/19 04:27

\/ . Andrew Lobanov to Difrex @ Re: Netmail 21/03/19 04:28

\/ . Difrex to Andrew Lobanov @ Re: Netmail 21/03/19 05:20

\/ . Andrew Lobanov to Difrex @ Re: Netmail 03/04/19 06:39

\/ . Difrex to Andrew Lobanov @ Re: Netmail 03/04/19 07:06

\/ . G2I to All @ Re: Netmail 03/04/19 11:37

\/ . Andrew Lobanov to All @ Дмитрий Хара "П. Ш." 22/05/19 04:34

\/ . Andrew Lobanov to All @ Фэхи 22/05/19 11:46

\/ . Anotheroneuser to All @ Сменить псевдоним 26/05/19 19:46

\/ . Andrew Lobanov to Anotheroneuser @ Re: Сменить псевдоним 27/05/19 07:29

\/ . Peter to Anotheroneuser @ Re: Сменить псевдоним 27/05/19 12:15

\/ . Anotheroneuser to Peter @ Re: Сменить псевдоним 27/05/19 16:53

\/ . Anotheroneuser to Andrew Lobanov @ Re: Сменить псевдоним 27/05/19 16:55

\/ . Andrew Lobanov to Peter @ Re: Сменить псевдоним 28/05/19 17:13

\/ . Peter to Andrew Lobanov @ Re: Сменить псевдоним 28/05/19 20:07

\/ . Andrew Lobanov to Peter @ Re: Сменить псевдоним 29/05/19 07:27

\/ . Difrex to Peter @ Re: Сменить псевдоним 31/05/19 08:10

\/ . Peter to Difrex @ Re: Сменить псевдоним 31/05/19 08:37

\/ . vit01 to All @ IDEC Mobile 15/06/19 11:02

\/ . vit01 to Andrew Lobanov @ Re: Дмитрий Хара "П. Ш." 08/07/19 03:45

\/ . vit01 to Andrew Lobanov @ Re: Фэхи 08/07/19 04:07

\/ . Andrew Lobanov to vit01 @ Re: Дмитрий Хара "П. Ш." 08/07/19 07:13

\/ . Andrew Lobanov to All @ Таверна 15/07/19 03:45

\/ . Difrex to Andrew Lobanov @ Re: Таверна 16/07/19 07:24

\/ . vit01 to Andrew Lobanov @ Re: Таверна 16/07/19 23:50

\/ . Andrew Lobanov to All @ Эталонная реализация idec 17/07/19 09:26

\/ . Difrex to Andrew Lobanov @ Re: Эталонная реализация idec 17/07/19 11:10

\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 12:29

\/ . Difrex to Difrex @ Re: Эталонная реализация idec 17/07/19 12:31

\/ . Peter to All @ https://club.syscall.ru 17/07/19 14:24

\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 15:50

\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 16:49

\/ . Difrex to Andrew Lobanov @ Re: Эталонная реализация idec 18/07/19 07:28

> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Ок, по стилю :)

Общие рекомендации:

* Код должен быть по PEP8.
* Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
нет докстрингов, не принимаются.
* Никогда не импортировать * из модулей.
* Не переопределять имена функций в переменные. Что я имею в виду:
В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
переменные с таким же именем. Это может привести к неочевидным последствиям.
Пример:

====

def h(x):
    return x * x


def some_method(func):
    val = get_val_from_rest_api()
    return func(val)


if __name__ == "__main__":
    h = "Template: {}"
    # Тут дальше идет какая-то логика
    # А под конец хотим вызвать какой-либо метод передав в него
    some_method(h
    # Получаем исключение, т.к. вместо функции мы передали строку

====

* Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Работает четко и круто.

Как облегчить себе жизнь и ваще не париться по поводу стиля:
Ставишь из своих репов autopep8, flake8, python-black, pip.
Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp

Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
за тебя GNU Emacs :)

+++ At work. idec.el/0.1

V9tRZj... . ОТВЕТИТЬ

\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 18/07/19 08:39

\/ . Peter to vit01 @ android idec и play market 20/07/19 06:41

\/ . Difrex to Peter @ Re: android idec и play market 20/07/19 07:17

\/ . vit01 to Peter @ Re: android idec и play market 20/07/19 11:09

\/ . Difrex to vit01 @ Re: android idec и play market 20/07/19 12:57

\/ . btimofeev to vit01 @ Re: android idec и play market 20/07/19 15:24

\/ . G2I to All @ Re: Netmail 21/07/19 07:47

\/ . G2I to All @ Re: Netmail 21/07/19 09:57

\/ . vit01 to btimofeev @ Re: android idec и play market 22/07/19 02:55

vit01>> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

btimofeev> Дополнительно можно в F-droid выложить. Могу с этим помочь.

Думаю, что F-Droid - это всё-таки наша первоначальная цель. Потому что это более "элитный" стор.

Difrex> Думаю, что мы можем задонатить =)

Это можно, но главное - это пофиксить неудобства юзабилити и дизайна + создать эталонную ноду, чтобы простые юзвери могли с удовольствием пользоваться клиентом. Вот в том же HodDogEd регистрация уже встроена в клиент, например. Нам до такой крайности опускаться не надо, но упросить порог вхождения желательно.

Самая нехорошая проблема для новичка - это первое скачивание сообщений. Надо его либо как-то ускорить, либо как-то подкрутить фетчер (для первого раза) на меньший лимит скачивания, чтобы всё побыстрее шло. И ещё пометить после первого фетча всё как прочитанное.

Ещё у меня на 9 андроиде после перезагрузки системы клиент падает с вот таким эксепшеном:

====

06-20 10:27:41.475 I/it01.idecmobil( 7793): Late-enabling -Xcheck:jni
06-20 10:27:41.976 I/Perf ( 7793): Connecting to perf service.
06-20 10:27:42.579 I/ACRA ( 7793): ACRA is enabled for vit01.idecmobile, initializing...
06-20 10:27:42.878 I/it01.idecmobile( 7793): type=1400 audit(0.0:101): avc: denied { getattr } for path="/data/data/com.android.keychain" dev="dm-0" ino=111211 scontext=u:r:untrusted_app:s0:c140,c256,c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=dir permissive=1
06-20 10:27:42.888 W/it01.idecmobil( 7793): Accessing hidden method Landroid/security/IKeyChainService$Stub;-><init>()V (dark greylist, linking)
06-20 10:27:42.889 D/AndroidRuntime( 7793): Shutting down VM
--------- beginning of crash
06-20 10:27:42.893 E/AndroidRuntime( 7793): FATAL EXCEPTION: main
06-20 10:27:42.893 E/AndroidRuntime( 7793): Process: vit01.idecmobile, PID: 7793
06-20 10:27:42.893 E/AndroidRuntime( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)
06-20 10:27:42.913 E/ACRA ( 7793): ACRA caught a NoSuchMethodError for vit01.idecmobile
06-20 10:27:42.913 E/ACRA ( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)

====

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

cyDzkU... . ОТВЕТИТЬ

\/ . Andrew Lobanov to All @ Re: Эталонная реализация idec 24/07/19 04:17

\/ . Andrew Lobanov to All @ Re: Эталонная реализация idec 24/07/19 08:29

\/ . Difrex to Andrew Lobanov @ Re: Эталонная реализация idec 24/07/19 13:43

> сделаете замечания
filter() - это встроенная функция python.

Т.е. делая так

====

from api import filter

====

Ты ее переопределяешь.

fuOsvd... . ОТВЕТИТЬ

\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 25/07/19 04:33

\/ . vit01 to All @ Странное письмецо, надо посоветоваться 25/07/19 15:41

Обратился ко мне по емейлу якобы владелец одного сайтеца, просит удалить ссылки с архива на alicorn.tk

====

Hi there,

I’m working on cleaning the website adaptavist . com, and I need your help in removing some links from your site. Your site is probably perfectly legitimate, but I’m just trying to eliminate as many links as possible.

I’m asking this because it’s come to our attention that some of the links to our website have been acquired against Google’s Webmaster Guidelines, so it’s important for us to remove links that are harming traffic to our website. Furthermore, by linking to our site, it could be detrimental to your site’s overall traffic, so it will be important for you to remove the link.

Here are some examples:

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Link text: ... (убрано мной, чтобы снова их скрипт не сработал)
Page on our site: ...

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply
Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=88

The link(s) need to be actually removed, rather than just disavowed. Even if they are “nofollow,” I’d still like them to be removed.

Please let me know if you have any questions. If you could email me once you have removed the link that would be great.

Thanks in advance! I hope to hear from you soon.

Kind Regards,

Adaptavist Webmaster

====

Мой ответ этим товарищам был вот такой:

====

These links which were mentioned by you, are actually from annotations of archived posts of the Habrahabr website
 
The traffic which comes to your website, is primarily caused by this habrahabr post: https://habr.com/ru/company/billing/blog/271805/ (for example)
 
We can try to get rid of those links, but it's just an archive of short abstracts from the "real" articles. So, I just wanted to make it clear why are you worried about them and if you contacted the author of the original habrahabr article

====

Что может посоветовать в этой ситуации многоуважаемый All?

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

5uBnA5... . цепочка . ОТВЕТИТЬ

\/ . Andrew Lobanov to All @ Тест 29/07/19 05:37

\/ . vit01 to Andrew Lobanov @ Re: Тест 29/07/19 07:17

\/ . Difrex to Andrew Lobanov @ Re: Тест 29/07/19 07:17

\/ . Difrex to vit01 @ Re: Странное письмецо, надо посоветоваться 29/07/19 07:25

\/ . Andrew Lobanov to vit01 @ Re: Тест 29/07/19 07:55

\/ . vit01 to Andrew Lobanov @ Re: Эталонная реализация idec 02/08/19 16:51

AL> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

Слабая валидация POST данных. Особенно на тех же файловых эхах

Способ хранения индексов вместе с файлами в фэхах меня тоже немного удивил. Можно попробовать в качестве атаки ввести фэху index и загрузить там файл с названием другой фэхи, тем самым легко затерев всё содержимое последней.

Мои пожелания:

1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"
Уже часто начал замечать, что при таком подходе гораздо проще делать бэкапы и отделять файлы репозитория от изменяемых файлов.

// все блэклисты и изменяемые конфиги полностью туда

К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

2. Объединить cli-скрипты в единый интерфейс и запускать вроде

====

idec.py run
idec.py points add Vasya
idec.py stats -f ... -t ...
idec.py stats --help

====

3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один

https://docs.python.org/3/library/argparse.html

4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

xIxlAp... . ОТВЕТИТЬ

\/ . vit01 to vit01 @ Re: Эталонная реализация idec 02/08/19 17:17

\/ . Andrew Lobanov to vit01 @ Re: Эталонная реализация idec 12/08/19 03:51

\/ . Difrex to All @ Форумное представление на dynamic 19/08/19 13:07

\/ . Peter to Difrex @ Re: Форумное представление на dynamic 20/08/19 07:42

\/ . Difrex to Peter @ Re: Форумное представление на dynamic 20/08/19 11:00

\/ . vit01 to Difrex @ Re: Форумное представление на dynamic 20/08/19 23:27

\/ . vit01 to All @ Ошибки в API и базе 20/08/19 23:39

\/ . Peter to vit01 @ Re: Ошибки в API и базе 21/08/19 08:37

\/ . Peter to vit01 @ Re: Ошибки в API и базе 21/08/19 10:16

\/ . vit01 to Peter @ Re: Ошибки в API и базе 21/08/19 19:03

\/ . Difrex to All @ Открытая статистика сети 02/09/19 13:14

\/ . vit01 to Difrex @ Re: Открытая статистика сети 18/09/19 14:32

\/ . jmaks to Andrew Lobanov @ ii node 02/11/19 16:13

\/ . vit01 to jmaks @ Re: ii node 03/11/19 17:19

Andrew Lobanov to jmaks @ Re: ii node 04/11/19 11:22