Более того — проблема решается банальнейшим образом через p2p (торренты, IPFS etc). Да и в общем-то куча файлообменников уже давно позволяет раздавать файлы по несколько гигов размером.
Тут ещё стоит добавить, что сами вектора могут позволять делать операции над ними. Соответственно вы можете сделать какие-то преобразования над "смыслами" и потом в базе искать что-то близкое к цели.
Условный пример (работает для некоторых видов эмбеддингов): если из вектора для слова "король" вычесть вектор для слова "мужчина" и прибавить вектор для слова "женщина", то вы получите вектор, близкий к вектору для слова "королева".
Я бы ещё добавил, что легко может оказаться так, что системы на базе LLM (ChatGPT и прочие) заберут ту нишу, которую сейчас занимают условные джуны и слабые миддлы. И даже те, кто недавно успешно прошёл курсы и трудоустроился - через год-два-три останутся без работы.
если у меня нет веба, нет томката — то нет и никакой проблемы вообще, потому что никакое выражение на SpEL никто снаружи засунуть в код не сможет?
Если вы совсем-совсем никаких данных никаким образом "снаружи" не получаете, то ваше приложение, действительно, не уязвимо к этой атаке (и к 99% любых атак в принципе).
На практике вы так или иначе получаете в приложение данные внешних источников. Если в процесс парсинга данных и биндинга их на POJO/DTO будет вовлечён Spring - вы всё ещё можете быть под угрозой. Сказать наверняка - трудно, так как подробностей всё ещё опубликовано мало.
Вот тут есть некоторая информация помимо той, что опубликована в Spring Blog:
Во-первых, на момент начальной публикации подробностей было намного меньше. Я бы даже сказал, почти не было.
Во-вторых, сама концептуальная проблема находится в Spring Core. А вот конкретный практически осуществимый вариант её использования для RCE — требует деплой через WAR на Tomcat.
300-500 в одном проекте, 300-500 в другом... Не успеешь и опомниться, как несколько гигабайт заняты под дублирующиеся файлы.
Ну и вообще с таким подходом не удивительно, что софт всё толще и медленнее с каждым годом. Ждём, когда через 10 лет будут говорить "Разве это проблема для пользователей с диском в 5-10 Тб. Сколько там ваши пакеты весят, 3-5Гб от силы?" :)
Это не сетевой слой где не нужно, это граница неверно проложена
Эм. А как она должна быть проложена? Вот логические сервисы, вот в монолите они общуются напрямую, а в микросервисах будет какой-то RPC. При чём тут граница? Как поможет "перенос границы" в другое место, если проблема изначально с тем, что поток данных очень "толстых", а требования по latency - очень жёсткие?
Более того — проблема решается банальнейшим образом через p2p (торренты, IPFS etc). Да и в общем-то куча файлообменников уже давно позволяет раздавать файлы по несколько гигов размером.
Тут ещё стоит добавить, что сами вектора могут позволять делать операции над ними. Соответственно вы можете сделать какие-то преобразования над "смыслами" и потом в базе искать что-то близкое к цели.
Условный пример (работает для некоторых видов эмбеддингов): если из вектора для слова "король" вычесть вектор для слова "мужчина" и прибавить вектор для слова "женщина", то вы получите вектор, близкий к вектору для слова "королева".
Зачем спекуляции и предположения в плане количества токенов, если можно запустить токенайзер от самого OpenAI?
https://github.com/openai/tiktoken
Из заголовка можно подумать, что производительность системы как-то однозначно и очевидно коррелирует с числом разработчиков (нет).
Я бы ещё добавил, что легко может оказаться так, что системы на базе LLM (ChatGPT и прочие) заберут ту нишу, которую сейчас занимают условные джуны и слабые миддлы. И даже те, кто недавно успешно прошёл курсы и трудоустроился - через год-два-три останутся без работы.
Пока что ChatGPT не очень трудно убедить, что "дважды два - пять".
А не важно, какие конкретно. Важно, что использовал (включил в модель).
Если вы совсем-совсем никаких данных никаким образом "снаружи" не получаете, то ваше приложение, действительно, не уязвимо к этой атаке (и к 99% любых атак в принципе).
На практике вы так или иначе получаете в приложение данные внешних источников. Если в процесс парсинга данных и биндинга их на POJO/DTO будет вовлечён Spring - вы всё ещё можете быть под угрозой. Сказать наверняка - трудно, так как подробностей всё ещё опубликовано мало.
Вот тут есть некоторая информация помимо той, что опубликована в Spring Blog:
https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
Во-первых, на момент начальной публикации подробностей было намного меньше. Я бы даже сказал, почти не было.
Во-вторых, сама концептуальная проблема находится в Spring Core. А вот конкретный практически осуществимый вариант её использования для RCE — требует деплой через WAR на Tomcat.
Актуальная информация из Spring Blog:
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
А разве уже где-то разработана технология выращивания нового органа с нуля в другом организме?
300-500 в одном проекте, 300-500 в другом... Не успеешь и опомниться, как несколько гигабайт заняты под дублирующиеся файлы.
Ну и вообще с таким подходом не удивительно, что софт всё толще и медленнее с каждым годом. Ждём, когда через 10 лет будут говорить "Разве это проблема для пользователей с диском в 5-10 Тб. Сколько там ваши пакеты весят, 3-5Гб от силы?" :)
Вот тут пример разбора: https://kungurov.livejournal.com/296999.html
Но одновременно другие тоже упали. Так что вряд ли.
Так они уже больше года этим безостановочно занимаются. Нет недели без новостей об обысках, задержаниях, закрытых НКО, медиа и т.д.
Они даже по официальной версии не являются сотрудниками милиции.
Весной 2021 озвучивалась цифра в порядка 40 тысяч (!) дел, связанных с протестами.
Эээ, а как же приговор за "мысленно поддерживал митингующих", который был вынесен в прошлом году судом в РБ?
https://charter97.org/ru/news/2020/11/30/402447/
Эм. А как она должна быть проложена? Вот логические сервисы, вот в монолите они общуются напрямую, а в микросервисах будет какой-то RPC. При чём тут граница? Как поможет "перенос границы" в другое место, если проблема изначально с тем, что поток данных очень "толстых", а требования по latency - очень жёсткие?
Ну, вы почему-то сразу про "вебхуки", хотя я про веб ни слова не говорил.