Хм. Судя по всему он просто делает checkout из зашифрованного гита в dev/shm
Вопрос: достаточно ли сделать rm -rf из dev/shm, чтобы гарантировать, что никто больше из этой области памяти не прочитает наши пароли?
Беглый гуглинг не дал результатов.
Просто всяческое crypto-по активно использует zeromemory и прочие гарантии удаления данных из памяти.
Как с этим в dev/shm?
С другой стороны — это супер идея, «я ее джва года ждал». Хранить под гитом пароли! Спасибо за наводку!
Так. UPD:
— Оба пункта относятся к шифрованию по маске **/*, т.е. полному шифрованию репозитория пофайлово.
— Как мне подсказывает KOLANICH в ToS Github нигде явно не зафиксировано, что в public репозиториях нельзя использовать обфурскацию/шифрование, так что стоит говорить лишь о fair use.
Также travis ci напрямую советует использовать шифрование.
Если, скажем, шифровать какие-либо ключи для travis ci — то оба мои возражения отпадают.
Технический — т.к. незашифрованные ключи обладают теми же свойствами, что и зашифрованные — они меняются не познаково, а целиком.
Моральный — т.к. кодом мы всё еще делимся, просто при этом защищаем наш pipeline от вандалов.
1. Технический аспект.
Отлично. У нас все зашифровано и любое малейшее изменение в файле ведет к полному изменению его зашифрованной копии.
Теперь посмотрим как работают pack-и git'а.
Они стараются хранить diff-ы файлов, чтобы предотвратить рост размера репозитория.
Проведите эксперимент — создайте два репозитория. Один в зашифрованном виде, другой — в незашифрованном.
Положите в них один и тот же файл размером в 50mb (для наглядности)
Измените в файле один символ и сделайте коммит.
Повторите это действие несколько раз. (На обоих репозиториях синхронно)
Теперь сделайте команду git gc на обоих репозиториях и сравните размер.
2. Моральный аспект:
«Если вы захотели воспользоваться публичным ресурсом вроде GitHub или GoogleDrive для хранения своего репозитория, но при этом не готовы делиться со всем миром результатами своего труда, то вам поможет»… приватный репозиторий от Github или собственный git-сервер.
Шифруя открытые репозитории, вы нарушаете свое соглашение с Github
В Телеграм нет смены ключа у закрытого чата.
Новый ключ можно получить только явно начав новый чат с тем же абонентом -> Оба абонента будут явно предупреждены о том, что это новый чат с новым ключом и ключ нужно снова сверять…
Т.е. если кто-то получил контроль над сервером уже после начала секретного чата между абонентами, единственный его вариант провести MITM — «убить» секретный чат. В этом случае абоненты попытаются (сознательно) снова установить соединение. Если они при этом не проведут верификацию ключей через сторонний канал — то они попадутся со своими котиками.
Но форсировать незаметную для пользователей перегенрацию ключей нельзя.
Если клиентские части приложения не патчить, конечно.
Это состояние называется прескевю. (presque vu) По аналогии с дежавю.
Самое печальное, что когда это случается со мной и я забываю слово «стропа» или «сугроб», я при этом всегда помню «presque vu».
Поэтому обычно это звучит как: «У меня опять presque vu, я забыл как называется длинные плоские эти… как их.»
Есть лайфхак, если вы придете в DNS, скажете «хочу вот это» не убивая мозг консультанта, а потом так жалобно «ну в технопоинте это же стоит вот столько?» (С видом как вам лень ехать до склада технопоинта), то продавец DNS может продать (и обычно продает) по цене Технопоинта.
В моем городе Технопоинт на окраине, а DNS в центре. Иногда бывает очень лень кататься. Постоянно так делал, еще ни разу никто не пошел на принцип…
Yep, от компании зависит. Я наблюдал компании где у бухов (возможно у всех сотрудников) по два компа — один с интернетом, другой с 1С и внутренними сервисами.
Т.е. air gap во всей красе. (На самом деле нет, т.к. можно из одной сети в другую протаскивать файлы — закидываешь файл на ftp в одной сети, через 5 минут он исчезает и появляется на таком же ftp в другой сети.)
Я сталкивался с таким феноменом — когда смотришь как играет кто-то другой, картинка кажется плавной, когда играешь сам — ощущение, что смотришь зажёванный диафильм. Не могу утверждать, что дело в input lag, просто набор субъективных ощущений.
Так FPS в играх вообще весь про input lag, утверждение, что «60 гарантированных FPS хватит всем» — это аналог утверждения «ни один мозг не заметит input lag при 60 (и выше) FPS „
Я всегда считал, что проблема в том, что 60 — это примерная нижняя граница, при которой input lag незаметен, поэтому минимальное проседание при активной игре (любой пропуск фрейма конвейером видеокарты) — как серпом по ганглиям.
Переводят книжку, Kali Linux-что-то там.
Почему в книжке про Kali Linux азы администрирования мне тоже непонятно.
Все жду, когда там про особенности конкретного дистрибутива появится.
Я знаю про швейцарскую армию и систему резервистов.
Просто резервисты — это такой теплый ламповый институт.
Как ганзейский союз и швейцарские гвардейцы.
Поэтому в моем воображении рисовалось, что они подчиняются выборной исполнительной власти в военное время. Типа резервисты конкретного города подчиняются городскому главе, который отвечает за их тренировку и снабжение=)
В итоге новость для меня как «хакеры взломали базу данных союза вольных городов»
А «министерство обороны» — это такой имперский монстр, у которого есть планы про нападение инопланетян, нападение на инопланетян и секретный бюджет на бомбу следующего поколения, которая может уничтожить мир не три раза, а четыре и не за пятнадцать минут, а за 8.
у кали есть forensic-mode, не цепляет ничего лишнего…
Но вообще да, они как-то as is debian взяли, про анонимность тут говорить не приходится, все нужно пилить самому…
По США вроде как только в ручной клади. (FAA:«Rechargeable and non-rechargeable lithium batteries, cell phone batteries, laptop batteries, external batteries, portable rechargers
Spare (uninstalled) lithium ion and lithium metal batteries must be carried in carry-on baggage only»)
Вопрос: достаточно ли сделать rm -rf из dev/shm, чтобы гарантировать, что никто больше из этой области памяти не прочитает наши пароли?
Беглый гуглинг не дал результатов.
Просто всяческое crypto-по активно использует zeromemory и прочие гарантии удаления данных из памяти.
Как с этим в dev/shm?
С другой стороны — это супер идея, «я ее джва года ждал». Хранить под гитом пароли! Спасибо за наводку!
— Оба пункта относятся к шифрованию по маске **/*, т.е. полному шифрованию репозитория пофайлово.
— Как мне подсказывает KOLANICH в ToS Github нигде явно не зафиксировано, что в public репозиториях нельзя использовать обфурскацию/шифрование, так что стоит говорить лишь о fair use.
Также travis ci напрямую советует использовать шифрование.
Если, скажем, шифровать какие-либо ключи для travis ci — то оба мои возражения отпадают.
Технический — т.к. незашифрованные ключи обладают теми же свойствами, что и зашифрованные — они меняются не познаково, а целиком.
Моральный — т.к. кодом мы всё еще делимся, просто при этом защищаем наш pipeline от вандалов.
git-scm.com/book/ru/v1/Git-изнутри-Pack-файлы
Отлично. У нас все зашифровано и любое малейшее изменение в файле ведет к полному изменению его зашифрованной копии.
Теперь посмотрим как работают pack-и git'а.
Они стараются хранить diff-ы файлов, чтобы предотвратить рост размера репозитория.
Проведите эксперимент — создайте два репозитория. Один в зашифрованном виде, другой — в незашифрованном.
Положите в них один и тот же файл размером в 50mb (для наглядности)
Измените в файле один символ и сделайте коммит.
Повторите это действие несколько раз. (На обоих репозиториях синхронно)
Теперь сделайте команду git gc на обоих репозиториях и сравните размер.
2. Моральный аспект:
«Если вы захотели воспользоваться публичным ресурсом вроде GitHub или GoogleDrive для хранения своего репозитория, но при этом не готовы делиться со всем миром результатами своего труда, то вам поможет»… приватный репозиторий от Github или собственный git-сервер.
Шифруя открытые репозитории, вы нарушаете свое соглашение с Github
Новый ключ можно получить только явно начав новый чат с тем же абонентом -> Оба абонента будут явно предупреждены о том, что это новый чат с новым ключом и ключ нужно снова сверять…
Т.е. если кто-то получил контроль над сервером уже после начала секретного чата между абонентами, единственный его вариант провести MITM — «убить» секретный чат. В этом случае абоненты попытаются (сознательно) снова установить соединение. Если они при этом не проведут верификацию ключей через сторонний канал — то они попадутся со своими котиками.
Но форсировать незаметную для пользователей перегенрацию ключей нельзя.
Если клиентские части приложения не патчить, конечно.
Самое печальное, что когда это случается со мной и я забываю слово «стропа» или «сугроб», я при этом всегда помню «presque vu».
Поэтому обычно это звучит как: «У меня опять presque vu, я забыл как называется длинные плоские эти… как их.»
В моем городе Технопоинт на окраине, а DNS в центре. Иногда бывает очень лень кататься. Постоянно так делал, еще ни разу никто не пошел на принцип…
Т.е. air gap во всей красе. (На самом деле нет, т.к. можно из одной сети в другую протаскивать файлы — закидываешь файл на ftp в одной сети, через 5 минут он исчезает и появляется на таком же ftp в другой сети.)
Какое-то время пост висел с «1» в счетчике комментариев, заходишь в пост — комментариев нет.
Я всегда считал, что проблема в том, что 60 — это примерная нижняя граница, при которой input lag незаметен, поэтому минимальное проседание при активной игре (любой пропуск фрейма конвейером видеокарты) — как серпом по ганглиям.
Или какой-то другой смысл в них?
Почему в книжке про Kali Linux азы администрирования мне тоже непонятно.
Все жду, когда там про особенности конкретного дистрибутива появится.
Просто резервисты — это такой теплый ламповый институт.
Как ганзейский союз и швейцарские гвардейцы.
Поэтому в моем воображении рисовалось, что они подчиняются выборной исполнительной власти в военное время. Типа резервисты конкретного города подчиняются городскому главе, который отвечает за их тренировку и снабжение=)
В итоге новость для меня как «хакеры взломали базу данных союза вольных городов»
А «министерство обороны» — это такой имперский монстр, у которого есть планы про нападение инопланетян, нападение на инопланетян и секретный бюджет на бомбу следующего поколения, которая может уничтожить мир не три раза, а четыре и не за пятнадцать минут, а за 8.
Но вообще да, они как-то as is debian взяли, про анонимность тут говорить не приходится, все нужно пилить самому…
thing = new TheThing()
assert(thing instanceof PortableRecharger);
assert(thing instanceof MovingCase);
??
По США вроде как только в ручной клади. (FAA:«Rechargeable and non-rechargeable lithium batteries, cell phone batteries, laptop batteries, external batteries, portable rechargers
Spare (uninstalled) lithium ion and lithium metal batteries must be carried in carry-on baggage only»)