Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

23.12.2022

Основи TLS - чому необхідно шифрування в інтернеті

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

Сучасні комп’ютери та смартфони вдало приховують той факт, що між нами та нашими співбесідниками, соціальними мережами, відео, банками та новинами стоїть мережа серверів розміром з цілий світ — Інтернет.

Легко помітити, що у твого компʼютера немає прямого дроту, що веде, наприклад, на сервер Телеграму. Замість того компʼютер звернеться до роутера, той — до провайдера, провайдер — на магістральний вузол, і так далі до дата-центрів Телеграму і до конкретної машини, що обробить запит. Все, що ми відправляємо чи отримуємо з Інтернету, проходить через десятки вузлів.

І друге, про що варто подумати — у цифрових даних немає ніякого вбудованого механізму приховування. Сама по собі передача даних відбувається у повністю відкритому вигляді. Всі наші дані може прочитати будь-хто з доступом до одного з цих вузлів. Та й більше того - проміжні сервери постійно читають їх та передають далі. А ось чи зберігають вони нашу інформацію - ми не маємо можливості дізнатись.

Отже, коли ти переписуєшся з кимось в Телеграмі, то це зовсім не приватна розмова. Навпаки — ваші повідомлення передаються з уст в уста через весь світ! До деякого моменту інтернет тримався на засадах довіри. Це не дивно для мережі, що виросла з університетських лабораторій. Все ж таки мережеві оператори — люди серйозні, та підглядати не будуть… то й можна їм довіряти. Зараз це так дико звучить, але ж не так давно ще ніхто не переймався.

Проблема шифрування вибухнула близько десяти років тому завдяки поширенню Wi-Fi. Бо відкритий (без пароля) Wi-Fi це набагато, набагато гірше ніж все, що було до того. Будь-хто, підключений до відкритого Wi-Fi, може підслухати все, що передається іншими клієнтами мережі. Навіть особливого обладнання не треба.

Саме відкритий Wi-Fi дав поштовх для масового переходу сайтів на шифрований протокол HTTPS. Підслуховувати його все ще можна, але не має сенсу, бо нічого не зрозумієш. Це корисно не тільки з підозрілим Wi-Fi, але з допитливими провайдерами, державними адміністраціями, та інше. Тепер важко знайти сайт без HTTPS, та браузери навіть починають забороняти такі сайти — задля нашої безпеки. Про те, що це таке - HTTPS - розкажу наступного разу.

22.12.2022

Основи TLS - сертифікати та ланцюг довіри

На цей час в уважного читача має виникнути питання — а як публічні ключі розповсюджуються? Та де взяти той самий публічний ключ, що відповідає серверу чи особі, та підтвердить їх автентичність?

Можливо, є якийсь реєстр публічних ключів, до якого можна звернутись? Така система нас не влаштовує, тому що вона потребує доступу до інтернету — у той час, коли інколи сам доступ вже вимагає автентифікації.

Відповідь контрінтуїтивна: публічний ключ нам передає його власник. Наприклад, у випадку підпису документа, публічний ключ прикладається до нього так само як і підпис. А у випадку вебсерверів, то сервер пришле нам свій ключ на початку сеансу. Оце так! Ми ж йому ще не довіряємо?

Для того, щоб прийняти ключ від невідомого субʼєкту, він передається у вигляді сертифікату. Сертифікат надає можливість автономної верифікації через ланцюг довіри.

Криптографічний сертифікат — то документ, що містить публічний ключ та додаткову інформацію — таку, як імʼя особи або сервера, контактні дані, та інше. Але головне, що будь-який сертифікат має підпис, наданий іншим сертифікатом. Найчастіше цей сертифікат належить центру сертифікації. А далі — як можна здогадатись — сертифікат цього центру також має підпис… Така послідовність підписів називається ланцюгом довіри. Закінчується ланцюг кореневим сертифікатом, який підписаний сам собою.

Кореневому сертифікату ми довіряємо тому, що він у нас є заздалегідь. Якщо на macOS відкрити програму Keychain Access, то ми зможемо побачити перелік кореневих сертифікатів. Кожного разу, коли ваша система перевіряє підпис, вона завжди проходить по ланцюгу довіри, поки не знайде відомий їй кореневий сертифікат.

У “Дії”, до речі, свій набір кореневих сертифікатів, а точніше, він належить державі Україні. Власне, для будь-якої потреби можна визначити кореневі сертифікати, яким ви довірятимете.

Якщо цікаво пороздивлятися сертифікати, раджу програму Keystore Explorer.

21.12.2022

Основи TLS - ключі та підписи

Отже, вчора розібралися з тим, що таке асиметрична криптографія та яке значення вона має для довіри в інтернеті. Тепер про ключі та підписи.

Про ключі я вже трохи говорив. Додам, що, на відміну від паролів, які можуть бути випадковими, ключі для асиметричного шифрування повʼязані математичною залежністю, тому ніхто їх ніколи не вигадує, а натомість генерує, наприклад, командою ssh-keygen.

Цікаво, що з одного боку, ключі уможливлюють автентифікацію: якщо я передам тобі свій публічний ключ, то потім ти можеш перевірити, що я — це я, тримач приватного ключа. Але з іншого — не містять визначної інформації: тобто хто я такий, по ключу зрозуміти не можна. Для цього нам потрібні сертифікати, та щоб дістатись до сертифікатів, треба спочатку зрозуміти підписи.

Що ж таке цифровий підпис? Насправді він робиться дуже просто — беремо документ для підпису, та шифруємо його приватним ключем. Це і є підпис. Тепер передаємо підпис отримувачу разом з оригінальним документом. Отримувач документа може розшифрувати підпис публічним ключем, порівняти з оригінальним документом, та зробити висновок про його дійсність.

(Зауважу, що насправді зазвичай підписується не весь документ, а його хеш, тому що хешування працює набагато швидше, ніж шифрування. Відповідно, отримувач перевіряє, що хеш документа збігається з розшифрованим хешем.)

Тепер ти знаєш, що відбувається, коли ми підписуємо документ у “Дії”, та чому це можна розцінювати як аналог звичайного підпису на паперу. Навіть більш безпечний, бо у документі з цифровим підписом технічно неможливо змінити жодного біту. “Дія” створює та зберігає за тебе приватний ключ, а ось де знайти відповідний публічний, розкажу завтра.

20.12.2022

Основи TLS - асиметричне шифрування

Сьогодні хочу розпочати серію постів про роботу TLS та HTTPS. Нехай то буде моїм “простим розʼясненням теорії категорій”. Мені доводилося багато стикатися з TLS, колись навіть робив MITM Proxy для підміни сертифікатів, та — уявіть собі! - для порядного клієнта з гарними намірами.

Щоб зрозуміти TLS, спочатку треба розуміти асиметричне шифрування.

Шифрування — то, сподіваюсь, широко відоме поняття. Але ми звикли до того, що для розшифрування потрібен пароль (ключ), та шпигуни ганяються за паролем чи там кодовим диском, щоб розкрити таємницю.

Але асиметричне шифрування замість ключа використовує пару ключів. Що зашифроване одним ключем з пари, можна розшифрувати іншим. Напевно, ти чув про публічний та приватний ключ — так от, принципової різниці між ними немає — вони взаємозамінні — окрім саме того, що один зберігається в секреті, а інший розкривають всім.

Це надає нам декілька цікавих можливостей. Якщо зашифрувати повідомлення публічним ключем, то прочитати його зможе тільки власник приватного. Це можна порівняти до роботи пошти. Але ще цікавіше, що якщо зашифрувати повідомлення приватним ключем, то будь-хто зможе не просто прочитати його, але й тим самим підтвердити автентичність — бо успіх розшифрування можливий тільки при використанні парного ключа.

Вся система довіри сучасного інтернету будується на цієї властивості.

Зазначу, що все шифрування на компʼютері працює з числами, бо будь-яка інформація зберігається у вигляді цифр, на то й цифрові технології. До того ж ніяких складних операцій там немає — тільки арифметика та бітова логіка, бо шифрування має працювати дуже швидко, на обсязі в гігабайти даних. Асиметричний алгоритм RSA складається з досить зрозумілої та цікавої арифметики простих чисел, я навіть колись робив його реалізацію. В чому ж тоді його безпечність? Прості числа, які використовуються як ключі в справжньому шифруванні, дуже великі, довжиною близько 600 цифр. Чим більше ключ — тим складніше підібрати до нього пару. На цей час компʼютери на це не спроможні. Настане день, коли це стане технічно можливим — тоді ми зробимо ключі ще довшими.

19.12.2022

Документація процесів як неодмінна частина розробки

Сьогодні задокументував один важливий процес в проєкті, про який знав один тільки я. Так вийшло тому, що я його і задумав, і реалізував наодинці, причому десь рік тому. Але поки не написав документації, робота була не завершена.

Я б розказав більше, але то справжнє ноу-хау, якого (наскільки я знаю) ні в кого на світі більше немає, тому ніяк не можу. А як воно здобувалось… це був скажений тиждень перебору розвʼязків та навіть напрямків — коли успіх всього проєкту залежав від однієї-єдиної ключової ділянки.

На жаль, документація не є обовʼязковою практикою сучасного програмування. Ми навчились використати системи контролю версій, писати тести, працювати в парі, але документація залишається на розсуд та бажання інженера. І, скоріш за все, залишається ненаписаною.

Щоб виправити нестачу документації, я б почав з високорівневого опису архітектури проєкту та переліку його загальних частин. Саме ці відомості важко отримати з коду: код розказує, як воно працює, але не що та особливо чому. Такий опис в нас вже є, у вигляді діаграми. Це безпосередньо корисно, щоб пояснити проєкт новому учаснику. Діаграму все одно треба постійно доповняти та чистити, бо інакше застаріла діаграма може бути гірше, ніж ніякої.

А далі, в ідеалі, кожне розʼяснення архітектури має закінчуватись новою главою документації. Таким собі внутрішнім RFC для команди. (Та, закладаюся, OpenAI з таким твором не впорається.)

18.12.2022

Компроміси баз NoSQL, а особливо Firebase Firestore

В серці кожної бази даних NoSQL лежить компроміс. Замість повноти та гнучкості SQL ми отримуємо швидкодію та здатність до масштабування. Та хоч через простоту ці бази виглядають схожими, насправді вони більше різноманітні та менше взаємозамінні, ніж бази SQL. Причина в тому, що кожна база NoSQL розрахована на конкретну форму роботи з даними — особливо запитів. Тому при виборі бази головне — зрозуміти, що її характер підходить під проєкт, та вже після того дивитись на швидкодію та популярність.

Так, одного разу я мало не обрав DynamoDB, бо вона здатна працювати “в масштабі планети”. Але в DynamoDB можна ставити запити або по ключу, або ж по індексах, що побудовані заздалегідь. Ці індекси фіксують не тільки поле для запиту, але й порядок результатів. Тому DynamoDB добре застосувати, коли структура запитів обмежена та добре відома; дизайн бази, фактично, зводиться до дизайну запитів.

А зараз замислився над тим, як реалізувати вибірку витрат на накопичення у Firebase Firestore. Річ у тому, що структура бази така, що витрати належать до бюджетів, а цілі накопичення існують окремо від них та мають збирати витрати з усіх можливих бюджетів.

Як я вже писав, у Firestore база складається з колекцій, вкладених у документи. Так от, базові запити завжди працюють в межах однієї колекції — по цей час це нас повністю влаштовувало. Щоб зібрати документи з різних колекцій, є запити до групи колекцій. Але “група колекцій” будує глобальний індекс, та щоб кожний користувач мав доступ тільки до своїх витрат, маємо додати фільтр по ID користувача. Але для цього ID користувача має міститись в самому записі — бо права доступу до групи колекцій вміють працювати тільки зі змістом записів. Раніше в цьому не було жодного сенсу, бо всі витрати користувача вкладені в документ користувача, та авторизація відбувається за шляхом. А тепер, напевно, доведеться додати.

Альтернативний підхід: просто робити копії витрат на накопичення у загальну колекцію. Тоді не потрібно ускладнювати записи, але доведеться робити дублікати. На щастя, Firestore підтримує атомічні операції, так що принаймні база залишиться консистентною.

Поки не вирішив, що краще — група колекцій для (дуже!) приватних даних виглядає ризиковано, але ж з іншого боку, це вбудована функція бази, на відміну від клонування записів.

17.12.2022

Як додати елементи панелі системного меню за допомогою SwiftBar

🦃🌼🎾 Якщо в тебе Мак та ти вмієш програмувати, варто знати про утиліту SwiftBar. Вона робить можливим додати елементи до панелі системного меню, написав скрипт, що виводить простий текст.

Головне, для чого це потрібно мені — це відстежувати статус тривог на наших серверах. Але можливості безмежні, що підтверджує каталог з сотнями готових скриптів. Та більш важливо, що написати свій — зовсім нескладно.

Дуже люблю такі рішення, коли зі зрозумілого текстового виходу роблять красивий результат. Навчитися писати ці скрипти можна за пʼять хвилин. А далі, оскільки вони виконуються локально, то можна залучити частини готового коду з проєкту, або за допомогою AppleScript отримати інформацію з інших програм, коротше, досягти результатів, на які не здатні готові додатки.

(Історична довідка: раніше був додаток BitBar, а потім її переписали та назвали xBar, але за моїм досвідом, SwiftBar - ще одна реалізація — стабільніше. Всі вони підтримують той самий формат конфігурації.)

16.12.2022

Автоматизація взаємодії з сайтами

🐰✍️🐰 Інколи доводиться автоматизувати деяку взаємодію з сайтом — або ж, інакше кажучи — доводиться її рутинно робити багато разів, а хочеться автоматизувати. От сьогодні мені довелося відновлювати близько 20 тисяч записів, кожний з яких треба завантажити через вебформу.

Не завжди обовʼязково для цього брати справжній браузер. Браузери повільні та складні. Це для інтеграційного тестування варто перевіряти в браузері, щоб переконатись, що додаток працює так, як треба. А для задач автоматизації можна згадати, що все, що робить браузер з сервісом — то посилає запити HTTP, а які самі — можна підглянути в консолі розробника.

Взагалі на Ruby для цього є пречудова бібліотека mechanize. На початку карʼєри рубіста мені чомусь довелось дуже багато зішкрібати інформації з сайтів, вона мені ще тоді полюбилась.

Але якщо треба ще швидше та ще простіше, то у Go найзвичайніший http.Client має можливість зберігати стан сеансу, якщо під’єднати до нього CookieJar. Так я й зробив, бо проєкт на Go. Далі, як вже казав, роблю один запит з імʼям та паролем, щоб авторизуватись, і потім відправляю свої записи.

Цікаво, що вебформа у цьому випадку є фронтендом для внутрішнього API. Тобто все це я роблю замість того, щоб відкрити прямий доступ до того API - це буде і небезпечно, і технічно складніше. А симуляція браузера — хоч і “некрасиве” рішення, але для поодиноких задач — кращий компроміс.

15.12.2022

Поради по вибору механічної клавіатури

⌨️🦾🧈 Пара порад про вибір механічної клавіатури, якщо може ви хочете купити комусь в подарунок, а особливо — собі.

На сьогодні фанати механічних клавіатур сформували цілу субкультуру, та тому може здатись, що такі клавіатури — то нішевий продукт для цінувачів дизайнерських клавіш та самостійної пайки. Але ж то не так. Механічна клавіатура приносить тактильне задоволення, доступне кожному. До того ж якщо у тебе десктоп або ти звик працювати з ноутбуком в закритому вигляді, то так чи інакше клавіатура потрібна, то чом би не купити хорошу?

Так-от. Як купити клавіатуру, що принесе задоволення? По-перше, переконайтеся, щоб клавіші були зроблені з PBT (а не з ABS). Саме матеріал клавіш визначає то саме тактильне відчуття, та PBT з усіх боків приємніше (хоч і дорожче.)

Далі, не переймайтеся з вибором вимикачів, а для роботи з текстом беріть коричневі, краще якщо Cherry, але не принципово. Коричневі дають чітке відчуття натиснення, та не дуже шумлять (але все одно порядно голосні.)

Ближче всього до клавіатури ноутбука буде розмір 75%. Треба дуже добре подумати перед тим, як брати менше. Більше — то ваша воля, залежно від потреб. До речі, я не помітив проблем з переходом з ноутбука на механіку або зі звиканням. Нормально працюю з обома по черзі.

Раджу заощадити на Bluetooth та взяти клавіатуру з дротом, або ж якщо бездротову, то з радіомодулем. Bluetooth додає затримку, для мене цілком помітну. Також можна на підсвітці заощадити, так легше буде вивчити напамʼять. :)

Нарешті, краще не ганятись за брендами типу Logitech або Razr, бо за моїм досвідом маленькі спеціалізовані компанії роблять краще. Думаю, якщо починати з фільтра PBT + Cherry MX, то результат 100% не розчарує.

14.12.2022

Як працює база Firebase Firestore. Обіцянки про Сінтру

Хочу в цьому вузькому, але публічному колі зобовʼязатись цього року доробити для Сінтри розділ заощаджень (принаймні, свою, технічну сторону.) Вже принаймні цілий рік збираємося, та на цей день заважають більше пріоритети, ніж війна та всі її мороки.

Перше, що доведеться зробити — це спланувати базу.

Як я вже писав, Сінтра працює на базі даних Firebase Firestore. Це дуже незвичайна база даних. Вона добре підходить для застосунків, де кожний користувач працює з обмеженим набором даних.

Оскільки Firestore - то і є ваш бекенд, що напряму спілкується з клієнтським кодом, то обмеження доступу забезпечуються безпосередньо в самій базі. Для цього є система правил безпеки. Вони виконують як валідацію, так і авторизацію. Правила не такі гнучкі, як повноцінний бекенд, проте дозволяють, наприклад. перевірити, чи є у користувача підписка. Статус підписки зберігається в іншому записі, а ось цей запис вже редагується тільки зі хмарної функції. Коли все, що не можна довірити клієнтському коду, можна сховати у хмарні функції, то обмеження системи правил прийнятні.

Наступне, це надзвичайна реактивність Firestore. На клієнті ми не здійснюємо запити до бази — ми підписуємося на зміни, та отримуємо їх автоматично. Це чудово римується з підходом Redux. На сервері також можна підписати на зміни хмарну функцію. Замість того, щоб опитувати базу, і будувати додаток на засадах “потягни, щоб оновити”, у нас все працює в реальному часі. Та, зазначу, це не досягнення нашого коду, а можливість бази.

Нарешті, цікаво, що база Firestore структурована у вкладені колекції документів: в корені є колекції, в них документи, у документа можуть бути вкладені колекції, в них ще документи, і так далі. Головне, на що це впливає — це права доступу — так, якщо розмістити всі документи користувача в підколекції одного корінного документа, то можна впевнено обмежити доступ до них. Також індекси обмежені колекціями. Запити до бази можливі тільки по індексах, що ми створили заздалегідь (або за ID). Тож грамотне розбиття даних по колекціях впливає на швидкодію.

Тож, для розділу заощаджень, потрібно спланувати додаткову структуру колекцій, документів та індексів таку, щоб, в першу чергу, було зручно підписуватись на них на клієнті. Додати їх до правил безпеки. Та після того можна перейти то інтеграції у Redux.

Раніше

Пізніше