Gitverse — новый российский репозиторий исходного кода

говнопалочную? не хочешь ли ты сказать, что выпуск сертификатов подтверждения подлинности, шифрование и прочие штуки это говнопалочная? отлично все сделано. многое появилось благодаря спамерам, они помогают улучшать почту. к слову, в прогрессивной телеге спам так и не забороли, а вот в почте я спам вижу благодаря всем этим костылям всего 1-2 раза в год.

с 98 на самом деле. в комменты фотку не приложить, но можешь на слово поверить.

И правильно.

Если машины работают, выполняют свои задачи, зачем бежать их заменять? Во имя чего, мистер Андерсон? (с)

я хочу сказать, что всякие dnsbl/spf/dkim абсолютно левые по отношению к smtp/pop/imap сущности. И «шифрование и прочие сущности» не должно быть в форме STARTTLS.

ну на днях я поднял сеть под досом и общался в телеге через ретранслятор в ирке. ну ты понел, нет ничего невозможного. переезжать с того досовского компа пока не планирую, там находится куча моих записей по проектам + вирусы уже не страшны, попробуй найди сейчас рабочий вирус под дос.

это тебе так кажется. половина хрени в сети настраивается через записи в днс, прикинь.

10.4. Ответственность СберТех в любом случае ограничена суммой 1 000 (одна тысяча) рублей, при наличии вины.

Пользовательское соглашение @

Ну а что, удобно. Никто и судиться не будет за такие деньги. Почему бы всем компаниям не вооружиться таким пунктом?!

я хочу сказать, что всякие dnsbl/spf/dkim абсолютно левые по отношению к smtp/pop/imap сущности.

Там только DKIM настраивается на стороне почтового сервера, на сколько я помню. Давно настраивал EXIM, вроде бы в нём прописывался приватный ключ DKIM. А в DNS указывался публичный ключ DKIM для сопоставления. Как то так. Всё остальное указывается в DNS.

В общем, email совершенствуется. Это адаптация под современные условия.

А так, много кто хочет переписать протоколы, но не у каждого получается. Вспомнить, к примеру, XMPP, который должен был стать стандартом для IM. Но он был слишком пухлым, и со своими «особенностями», часть из которых были очень не удобны.

К сожалению, «сделать нормально» пока ни у кого не получилось. И дело не в том, что плохие алгоритмы или плохой протокол.

Да нет, дело как раз в них.

Криптография — это только 30-40% алгоритмов и протоколов, а остальное — оргмеры. Дело в том, что криптография лежит на стыке реального мира и информационных технологий.

Ну так у тебя в PGP протоколы говно изначально. Их оргмерами затыкать – как жопой затыкать дыру в стене.

Тем не менее, задачу обмена ключами и их верификации можно сильно облегчить в сравнении с тем, что предлагает PGP. И это при том, что основные проблемы PGP не связаны с обменом ключами. PGP не предлагает ничего для forwards и backwards secrecy. Если твой ключ утёк, все записанная заранее переписка становится доступной. Эта проблема решена уже лет 10 минимум с помощью double ratchet.

Плюс, связка PGP+Email страдает от того, что зашифровано только тело сообщения. Заголовки и метаданные не шифруются никак. Остаётся только страдать.

с 98 на самом деле. в комменты фотку не приложить, но можешь на слово поверить.

Верю конечно. На ЛОРе хватает упоротых, комп с древней вендой для почты – это по местным меркам относительно вменяемо.

у почты нормальные протоколы, очень простые и хорошо документированные. менять ничего не нужно.

Разупорись, чувак. Ты спеки IMAP видел, вообще? Там хтонь подзалупная!

Зацени вот этот доклад, он как раз про реализацию IMAP с нуля и про то, какой это ад: https://fosdem.org/2024/schedule/event/fosdem-2024-2647--protocols-things-we-wish-we-knew-before-starting-an-imap-library/

вирусы уже не страшны, попробуй найди сейчас рабочий вирус под дос

Дос ассимилирует современный вирус и вирус станет частью доса. :)

У меня для тебя плохие новости. Все компании в пользовательском соглашении имеют подобный пункт.

дким, дмарк, спф, все это нужно чтобы роутить почту. его раньше не было просто потому, что и проблем таких не было, все полагались на честное слово. это нормально если источник подлинности почты с домена прописывается в самом же домене, ведь домен имеет проверку подлинности.

я читаю твой ответ как «я не осилил разобраться с простым имап протоколом, который по сути обмен plain текстом».

я читаю твой ответ как «я не осилил разобраться с простым имап протоколом, который по сути обмен plain текстом».

Нет, это по сути обмен s-expr, которые не plain текст. Плюс там 70 расширений к протоколу, которые могут использовать или не использоваться. Плюс отсутствие эталонной реализации, а значит разные сервера имеют разные глюки, которым надо соответствовать. Плюс ошибки в самом стандарте: ещё раз повторю, в стандарте написаны примеры, которые не соответствуют спеке. Просто потому что никто их не проверял.

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

Я сейчас проверил GitHub и Яндекс, там воздержались такое писать.

в гитхабе есть пункт где тебя могут забанить и удалить без объяснения причин как факт.

Как и везде. В том же СберТехе и Яндексе.

покаж это у сбера

4.1.5. удалять Контент, размещенный на Сайте и в Сервисе без каких-либо причин и без предупреждения Пользователя;

4.1.9. удалить Аккаунт Пользователя по своему усмотрению, в том числе в случае совершения Пользователем действий, нарушающих законодательство Российской Федерации (применимое законодательство) или положения настоящего Соглашения.

ок, уговорил

Да нет, дело как раз в них.

Они были первыми. Потом PKI. Тоже не айс, ждем лучшего.

Ну так у тебя в PGP протоколы говно изначально. Их оргмерами затыкать – как жопой затыкать дыру в стене.

Оргмерами не затыкают, на них полагаются. Собственно, наличие нотариата (ака CA) — это тоже оргмера, призванная установить взаимное доверие между участниками обмена.

Если твой ключ утёк, все записанная заранее переписка становится доступной. Эта проблема решена уже лет 10 минимум с помощью double ratchet.

Это верно, но с любая хранимая зашифрованная информация подвержена такой опасности, чем бы она не была шифрована. Я впервые от тебя узнал про double ratchet и пока не понял до конца как это работает. Но, насколько я смог понять, это улучшение протокола для обмена сообщениями «здесь и сейчас» и про периодическую перегенрацию сеансовых ключей. Там же явно сказано, «for instant messaging». Для подписи и верификации подлинности это все мимо кассы и не про то.

какая еще эталонная реализация?

Это такой кусок кода, который можно запустить.

эталон написан в рфц английским по белому, а дальше как обычно все дрочат как хочат.

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

история та же, но гугл ты наверняка любишь, а вот к рфц у тебя какая-то ненависть.

Ты проецируешь. К гуглу у меня очень холодное отношение. Тем не менее, без эталонной реализации, совместно с которой можно протестировать твой код, получается обычно говно. Что и получилось для Email.

Кстати, в последний раз когда я интересовался, через гуглопочту ходило что-то около 70% всего email трафика. Так что гугл сломал твой email тоже лол!

Да нет, дело как раз в них.

Они были первыми. Потом PKI. Тоже не айс, ждем лучшего.

Вообще насрать кто был первым. Мы сейчас говорим про сегодня, не про то что было в 1980 году.

Если твой ключ утёк, все записанная заранее переписка становится доступной. Эта проблема решена уже лет 10 минимум с помощью double ratchet.

Это верно, но с любая хранимая зашифрованная информация подвержена такой опасности, чем бы она не была шифрована.

Речь про пересылку, не про хранение.

Я впервые от тебя узнал про double ratchet и пока не понял до конца как это работает.

С разморозкой! Сходи видео на ютубе посмотри, их там есть пачка. В computerphile точно было.

Но, насколько я смог понять, это улучшение протокола для обмена сообщениями «здесь и сейчас» и про периодическую перегенрацию сеансовых ключей.

Да. А ещё про pre-keys.

Там же явно сказано, «for instant messaging».

Email – это «instant messaging».

Для подписи и верификации подлинности это все мимо кассы и не про то.

Безусловно. Мой посыл тут про убогость использования PGP в связке с Email. Впрочем, адекватные замены PGP для шифрования, подписи и верификации оффлайновых данных тоже существуют.

Это такой кусок кода, который можно запустить.

што? тебе подробнейшего рфц недостаточно чтоб написать код где идет тупейший обмен текстовыми командами? мне кажется тут попахивает непрофессионализмом и желанием копипастить со стак эксченджа

возможны разночтения

никогда в жизни не видел разночтений в рфц. стандарты пишутся буквально как нужно делать без додумываний. ну а если у тебя проблемы с реализацией и пишешь жопой, то тут надо просто опыта набраться чтоб с жопы опуститься до написания пяткой левой ноги.

эталонные реализации свои оставь в своей фантации, инженеры руководствуются рфц и пишут по нему. если они не вывозят значит они не вывозят и стандарт тут не причем.

што? тебе подробнейшего рфц недостаточно чтоб написать код где идет тупейший обмен текстовыми командами?

Я этим ни разу не занимался. Но как ты можешь видеть, сегодня почему-то этого недостаточно, и написать по этому стандарту работающий клиент нельзя. Потому что сервера клали болт на этот стандарт.

эталонные реализации свои оставь в своей фантации, инженеры руководствуются рфц и пишут по нему. если они не вывозят значит они не вывозят и стандарт тут не причем.

АХАХАХАХАХАХАХ! Сходи в Development тут, пообщайся с сишниками. Они сишный стандарт люто ненавидят, например. Тебе понравится!

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

а что там у сишников? темплейты не осилили или че? рассказывай, мне жутко интересно.

https://docs.github.com/ru/site-policy/github-terms/github-terms-of-service#n-disclaimer-of-warranties

Вы принимаете на себя полную ответственность и риск потерь в результате загрузки и/или использования вами файлов, информации, контента или других материалов, полученных с помощью Сервиса.

И куча других пунктов «если что, мы не несём ответственность».

никто не кладет болт на стандарты

Гугл поклал. Сходи посмотри как они точку в email адресах интерпретируют. Спойлер: для гугла нет разницы между some.address@gmail.com и someaddress@gmail.com. В гугле это один и тот же адрес.

https://support.google.com/mail/answer/7436150?hl=en

а что там у сишников? темплейты не осилили или че? рассказывай, мне жутко интересно.

Им компилятор, написанный согласно стандарту, код портит.

ну это ж гугл, контора гондурасов, они и веб ломают постоянно. корпорация добра же, че. у других компаний все хорошо со стандартами.

Никто и никогда не несет ответственность. Это и так понятно. А если и несёт, то вот держи свои 1000 деревянных. Про конкретную сумму компенсации и шла речь.

GitHub https://docs.github.com/ru/site-policy/github-terms/github-terms-of-service#p-release-and-indemnification

Вы соглашаетесь возместить нам убытки, защитить нас и оградить нас от любых и всех претензий, обязательств и расходов, включая гонорары адвокатов, возникающих в результате использования вами Веб-сайта и Сервиса, включая, помимо прочего, ваше нарушение.

Очень интересно 🤦

ну это ж гугл, контора гондурасов, они и веб ломают постоянно. корпорация добра же, че. у других компаний все хорошо со стандартами.

Да, всё так. Остальные крупные конторы не менее гондурасны. И, я повторю, через GMail на сегодня идёт минимум 70% всего email трафика в интернете.

ну пусть идет, главное что мой почтовый сервер подчиняется стандарту и правильно обрабатывает мою почту.

что всякие dnsbl/spf/dkim абсолютно левые по отношению к smtp/pop/imap сущности

А разве CA для HTTPS не тоже совершенно левая штука?

И «шифрование и прочие сущности» не должно быть в форме STARTTLS

Если бы вы прочли докуметацию, то узнали бы, что есть порты для соответствующих сервисов шифрованные «по умолчанию» (imaps/smtps например - на портах 993/465).

Так что «мимо».

Попросить можно, исправить нельзя. Нет технической возможности.

ну пусть идет, главное что мой почтовый сервер подчиняется стандарту и правильно обрабатывает мою почту.

А потом GMail начнёт дропать твои письма, потому что твой сервер – не сервер, и вообще иди нахрен мальчик. Они так любят делать с маленькими серверами.

А разве CA для HTTPS не тоже совершенно левая штука?

Левая. Но она не для https таки, а для нижележащего SSL.

Если бы вы прочли докуметацию, то узнали бы…

Я в курсе, и эти варианты нормальные.

Email – это «instant messaging».

Не совсем. Ты шифруешь и подписываешь сообщение на адресата на его и своих ключах. Потом отдаешь полученный бандл MTA. А когда и через какие сервера твой MTA этот бандл твоему адресату переправит ты в душе не разумеешь вообще-то. Instant messaging — это если мы с тобой в телеге (вацапе, сигнале, whatever) переписываемся напрямую и «вотпрямщас». Возможно, через ретранслятор, если мы оба за NATом сидим. Но ретранслятор, в этом случае, должен быть прозрачным, а не «человеком посередине» (в чем лично я не совсем уверен, несмотря на все громкие заверения про «сквозное шифрование» и секретные чаты).

Мой посыл тут про убогость использования PGP в связке с Email. Впрочем, адекватные замены PGP для шифрования, подписи и верификации оффлайновых данных тоже существуют.

Убого и устарело, да. Ждем замены. Если есть протокол лучше, то не факт, что он будет внедрен хотя бы по экономическим соображениям. Инфраструктуру менять влом и дорого.

Ты шифруешь и подписываешь сообщение на адресата на его и своих ключах. Потом отдаешь полученный бандл MTA. А когда и через какие сервера твой MTA этот бандл твоему адресату переправит ты в душе не разумеешь вообще-то.

Ты сейчас буквально любой чат описал.

Кстати, ещё один минус в коробку Email+PGP: нельзя нормально отослать шифрованное сообщение нескольким адресатам.

Но ретранслятор, в этом случае, должен быть прозрачным, а не «человеком посередине»

Чо? Любой промежуточный сервер будет «человеком посередине».

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

MLS только недавно допилили. Надеюсь, на его основе появится замена Email.

Но, на самом деле, всем просто посрать, потому что email сегодня кроме пары древних задротов и пачки корпорастов никто для переписки не использует. Все в чатиках сидят. Такие дела.

«Какая тебе награда будет?» (Иисус Иосифович Христос) Это лично от меня пожелание. Коллеги открыты к общению и адекватно воспринимают критику и баги. Хочешь — помоги.

Не, не так. Потестируем пока так. А новость да, лично меня попросили написать в частной беседе за фуршетом после всяких докладов. Ну вот, выполняю обещание. Но «мопед не мой, а просто дал объявление».

ЯНХНП, фуршет продолжается?

Я рано ушел. Может и танцы на столах были, но уже без меня :)

Старые аккаунты работают. Новые нет.

Работают, если через VPN. С российских ip не пускают.

Существует ли отечественный дистрибутив с нуля написаный?

Дистрибутив - это форма распространения программного обеспечения.

Но если ты считаешь, что, например, у Alt или Calculate, в установщике перебиты копирайты, то так бы сразу и заявил.

Только вот это gitea.

Это gitea, над которой мощно поработали и откололи примерно все. Снимаю шляпу, не знал, что можно так перебить шильдик, что аж все стекла выбило. Но allow_only_contributors_to_track_time осталось =)

Но, на самом деле, всем просто посрать, потому что email сегодня кроме пары древних задротов и пачки корпорастов никто для переписки не использует. Все в чатиках сидят. Такие дела.

Ой вей, таки 4.2. В популярной среди детей игре Genshin Impact в качестве логина используется email.

Github когда открыли, если не секрет?