Сегодня на medium был опубликован пост от разработчиков Flow, про то, почему от них так давно не было новостей.
Пишут о том, что последний год решали фундаментальные проблемы Flow: скорость и оптимизацию потребления памяти. Оптимиазция по скорости снизила число запросов от IDE, занимающих более одной секунды, с 1 млн./день до 25 тыс./день. Уважают решение разработчики сторонних библиотек о переходе с Flow на TypeScript, но для Facebook Flow остается очень важной технологией. Еще обещают быть более открытыми по поводу своих планов на будущее.
https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f
#flow
Пишут о том, что последний год решали фундаментальные проблемы Flow: скорость и оптимизацию потребления памяти. Оптимиазция по скорости снизила число запросов от IDE, занимающих более одной секунды, с 1 млн./день до 25 тыс./день. Уважают решение разработчики сторонних библиотек о переходе с Flow на TypeScript, но для Facebook Flow остается очень важной технологией. Еще обещают быть более открытыми по поводу своих планов на будущее.
https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f
#flow
Прочитал интересную статью Джека Арчибальда про относительно недавний хак npm-пакета event-stream. В ней очень много дельных советов про то, как свести к минимуму подобные атаки и ликвидировать их последствия.
Чтобы вредоносный пакет не смог своровать ваши ssh-ключи с компьютера или что-нибудь натворить на сервере, используйте сандбоксинг с помощью Docker или обычную виртуальную машину во время разработки. С предотвращением атак на пользователей сайта, на котором работает вредоносный скрипт, всё гораздо сложнее. Для себя я выделил следующие моменты: аудит зависимостей тех приложений, которые работают с финансами, разделение процесса сборки на два этапа (“trusted”, “untrusted”) и подключение на сайт политик csp, чтобы минимизировать риски для атакованного пользователя.
Ещё в статье мне понравился интересный трюк с полной очисткой всех сохранённых сайтом данных (куки, кеши, localStorage, sessionStorage и т. п.) Для этого серверу достаточно отправить http-заголовок
https://jakearchibald.com/2018/when-packages-go-bad/
#security #npm
Чтобы вредоносный пакет не смог своровать ваши ssh-ключи с компьютера или что-нибудь натворить на сервере, используйте сандбоксинг с помощью Docker или обычную виртуальную машину во время разработки. С предотвращением атак на пользователей сайта, на котором работает вредоносный скрипт, всё гораздо сложнее. Для себя я выделил следующие моменты: аудит зависимостей тех приложений, которые работают с финансами, разделение процесса сборки на два этапа (“trusted”, “untrusted”) и подключение на сайт политик csp, чтобы минимизировать риски для атакованного пользователя.
Ещё в статье мне понравился интересный трюк с полной очисткой всех сохранённых сайтом данных (куки, кеши, localStorage, sessionStorage и т. п.) Для этого серверу достаточно отправить http-заголовок
Clear-Site-Data: *, браузер почистит всё сам, но работает пока это только в Chrome и Firefox.https://jakearchibald.com/2018/when-packages-go-bad/
#security #npm