Программирование

DEFCON 21. Одних паролей недостаточно, или почему «ломается» шифрование диска и как это можно исправить. Часть 1

Существуют забавные штуки, такие, как монотонно возрастающие счетчики, с помощью которых можно контролировать активность TMP, а затем проверять полученные значения. Есть небольшой диапазон энергонезависимой памяти, который можно использовать для ваших нужд, он не такой большой, как килобайт, но тоже может быть полезен. Там имеется счётчик тактов, который позволяет определить, как долго система работает с момента последнего запуска. Имеются команды, которые вы могли бы дать TMP, чтобы заставить его делать вещи от вашего имени, в том числе очистку собственной памяти при необходимости.



Затем мы хотим разработать протокол, который пользователь может запустить на компьютере, чтобы убедиться, что компьютер не был взломан, прежде он аутентифицируется на компьютере и начнёт им пользоваться. Что полезного для такого протокола мы можем попробовать «запечатать» в регистры конфигурации платформы?

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

Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python. Так же хотелось бы на выходе иметь один бинарный файл, который будет легко запустить. И не возиться слишком много с memory management'ом.

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

У Go относительно простой синтаксис, неплохая стандартная библиотека, есть garbage collection, и на выходе мы получаем один бинарник. Казалось бы, что еще нужно?

Не так давно Kotlin так же стал пробовать себя на схожем поприще в форме Kotlin Native. Предложение звучало многообещающе — GC, единый бинарник, знакомый и удобный синтаксис. Но все ли так хорошо, как хотелось бы?

Спасибо всем, что пришли, сегодня мы поговорим о полном шифровании жёсткого диска (FDE), которое не так безопасно, как вы думаете. Поднимите руки, кто шифрует таким образом HDD своего компьютера. Поразительно! Ну что же, добро пожаловать на DefCon!



Похоже на то, что 90% из вас используют для шифрования диска программы с открытым исходным кодом, чтобы иметь возможность провести их аудит. Теперь пусть поднимут руки те, кто полностью выключает компьютер, если оставляет его без присмотра. Я думаю, примерно 20% присутствующих. Скажите, а кто вообще оставляет свой компьютер без присмотра на несколько часов, всё равно, включён он или выключен? Считайте, что я задаю эти вопросы, просто убедиться, что вы не зомби и не спите. Я думаю, что практически всем приходилось оставлять свой компьютер хотя бы на несколько минут.

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

Привет, Хабр! Уже много сказано об образовании, в частности для программистов, о программах, что лучше подходят или не подходят, но каждый год ситуация меняется и как бы грустно не было, в этом надо разбираться (будь ты абитуриент или работодатель). Очень важно начать свой путь именно с выбора alma mater… Прошу под кат всех, кого не испугает длинная статья по теме.

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

Каждый раз, создавая очередное корпоративное Java-приложение на основе Spring, вам необходимо повторять одни и те же рутинные шаги по его настройке:

• В зависимости от типа создаваемого приложения (Spring MVC, Spring JDBC, Spring ORM и т.д.) импортировать необходимые Spring-модули
• Импортировать библиотеку web-контейнеров (в случае web-приложений)
• Импортировать необходимые сторонние библиотеки (например, Hibernate, Jackson), при этом вы должны искать версии, совместимые с указанной версией Spring
• Конфигурировать компоненты DAO, такие, как: источники данных, управление транзакциями и т.д.
• Конфигурировать компоненты web-слоя, такие, как: диспетчер ресурсов, view resolver
• Определить класс, который загрузит все необходимые конфигурации

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.

Всем привет!

В этой статья я продемонстрирую основные компоненты для создания Reactive RESTful миксросервисов, используя Spring WebFlux, Spring Security, Spring Cloud Netflix Eureka (Service Discovery), Hystrix (Circuit Breaker), Ribbon (Client Side Load Balancer), External Configuration (через git repository), Spring Cloud Sleuth, Spring Cloud Gateway, Spring Boot Reactive MongoDB. А также Spring Boot Admin и Zipkin для мониторинга.

Продолжаем, самое легкое позади! А теперь к самому сложному и интересному. Если лень читать, то ниже (ближе к концу статьи) будет ссылка на видео, с результатом и объяснением всего, в том числе и того, что описано в первой части. Кому интересно, то прошу следовать далее.

Дональд Кнут, мастер алгоритмов, размышляет над 50 годами работы над своим главным творением, книгой «Искусство программирования», которую не прекращает дополнять

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

Уже полвека стэнфордский специалист по информатике Дональд Кнут, немного напоминающий Йоду – хотя ростом он 193 см и носит очки – занимает доминирующее положение духовного учителя в области алгоритмов.

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

Тем не менее злые начальники требуют больше тестов, говоря о так называемом «контроле качества». Особо хитрые менеджеры даже считают покрытие и не отпускают вас с работы, пока оно не будет достигнуто. Ваш код заворачивают на ревью, если в нём нет тестов или они чем-то не понравились. Сплошное расстройство!

Что же делать?