Нет, ваш запрос curl написан некорректно. Ошибка в "[0-20:10]" — это невалидный способ указания диапазона в URL. Google не поддерживает такую запись в параметрах запроса.
а причем тут поддержка гуглом параметры и про какую ошибку вы говорите? затестить не судьба?
Создадим цикл от 0 до 20 с шагом в 10. Таким образом получим три значения: 0, 10 и 20, которые подставим в парсер поисковика. Цикл будет выглядеть следующим образом:
Выглядит интересно, SAST в Gitlab включается и настраивается легко. Есть много инструментов, которые могут дополнять друг друга.
Скорее всего они делают тоже самое что и semgrep
В целом и сам Gitlab потихоньку двигается в сторону уменьшения инструментов, объявляя, что перестает поддерживать некоторые из них (например, Bandit, ESLint, GoSec).
Поэтому иногда имеет смысл подключить инструмент самостоятельно. Покажу на примере все того же Semgrep.
На досуге возьмите semgrep базовый и контейнер из gitlab, просканируйте одну и туже кодовую базу, и сравните результаты. Боюсь разница вас смутит... з.ы. не хочу сказать что концептуальная разница в сканнерах, но показатели work time и выявленные дефекты будут существенно отличаемы.
Зоопарк технологий. Под каждый ЯП — свой набор инструментов, каждый из которых может работать по-своему. Например, phpcs-security-audit выполняется не под рутом, а это значит, что мы не можем установить свои либы (jq, bash и т. д.).
FROM registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest
USER root
RUN apk update && apk add git curl
в alpine нету bash, в alpine ash
Но есть и минусы:
GitLab может ограничивать возможности инструмента;
GitLab может не так активно актуализировать версии инструментов.
Update
Во многих языках программирования есть пакетные менеджеры, при помощи которых мы можем выкачивать код, и информация об этом сохраняется в различных файлах (go.sum, composer.lock, package-lock.json, yarn.lock, Gemfile.lock, requirements.txt и т. д.). Dependency Scanning-инструменты сканируют эти файлы, смотрят, какие пакеты были выкачаны и какие были версии, далее пакеты проверяют в базе скомпрометированного ПО и, если их там находят, выдают ошибку.
Проблема, которая решается в голове за 2 секунды действительно стоило написания и публикации статьи?
Вы конечно меня простите, но если это для вас открытие, добавьте хоть идейности и значимости в статью:
Какие лимиты на данный запрос после чего вам откажут мило в выдаче поисковых результатов?
Когда телеграм посчитает это злоупотреблением и что будет с акаунтом и после какого предупреждения читатели решившие повторить опыт будут "добрым" словом отзываться об этой статье?
Какой алгоритм на ваш взгляд используется в поиске юзернеймов?
А что если аккаунт без юзернейма впринципе?
Это весьма примитивные так-же вопросы, есть и более интересные и сложные - однако не всем такой опыт вообще нужен. Но минимально добавить полезности же не сложно, а то такое ощущение что открыли для себя один из методов работы поиска подстроки в форме поиска... Не сочтите за любые формы осуждения - но согласитесь добавив деталей, минимально о кейсе, эта статья будет куда полезнее читателям
In addition these also provide a way to retrieve a user's PGP keys:
GitHub:
https://github.com/USER.keys
https://gitlab.com/USER.gpg
GitLab:
https://gitlab.com/USER.keys
https://gitlab.com/USER.gpg
Да я вижу вектор мыслей автора, собрать все pub-key ssh не великая проблема. (Конечно же gh-archive/gh-torrent не включает подобные данные).
Вроде не раз уже собиралось подобное по порту 22.
Но в контексте безопасности, безусловно есть "рычаги" влияния. Но в контексте концепции криптографии - приватный ключ должен быть в безопасности. Да великая проблема в том что мы не можем отслеживать попытки применения приват ключа. Но best practice гласит: используйте уникальную пару на сервис (ровно как и пароль), заменяйте регулярно пару (как гласит практика плановой смены "паролей", но в данном контексте ключ).
Есть ли смысл выставлять на всеобщее обозрение кейсы имеющие влияние на OA комьюнити? Сомневаюсь...
2. К сожалению не находим ничего полезного по почте, кроме никнейма, который уже просмотрели выше.
К сожалению почта на mail.ru + есть страничка в моем мире. Тырк, — «я все скажу»
— Логика элементарна, http://my.mail.ru/mail(bk|list|inbox)/username/
Где username — все до @, почтовый домен идет перед /username
99% выше изложенное = спс кэп.
Но проанализируйте теперь данные которые присутствую практически на всех страницах профиля мой мир, и откройте заявку на восстановление доступа к почтовому ящику, страничка где в саппорт заполняется анкетка. Обратите внимание на обязательные пункты в ней и на данные которые по дефолту содержит мой-мир.
з.ы. не забудем тот факт, что проверка идет по данным на которые регался почтовый акк… и унификацию данных профиля между сервисами мейл.ру. Мб я просто не наше функции поменять к примеру имя только в моем мире, или эта фича появилась за последнее время. Но суть я надеюсь передал)
И мне "жетон"
Похоже на правду - gpt тык
стандартный конец ответа gpt, тем более сейчас в ответах gpt 4o приноровился эмодзи с ракетой добавлять 😑
а причем тут поддержка гуглом параметры и про какую ошибку вы говорите? затестить не судьба?
магия?
В curl есть поддержка url подстановки числового диапазон, цикл не к чему
Скорее всего они делают тоже самое что и semgrep
Почему? Потому что портированы практически все правила с bandit, eslint, gosec в правила semgrep https://gitlab.com/gitlab-org/security-products/sast-rules
На досуге возьмите semgrep базовый и контейнер из gitlab, просканируйте одну и туже кодовую базу, и сравните результаты. Боюсь разница вас смутит... з.ы. не хочу сказать что концептуальная разница в сканнерах, но показатели work time и выявленные дефекты будут существенно отличаемы.
в alpine нету bash, в alpine ash
Если бы было все так просто...
К ознакомлению попрошу изучить данную статейку - https://www.endorlabs.com/learn/why-are-all-sca-tools-wrong
Ознакомиться с подходом syft'а "catalogers"
з.ы. дальше статью не осилил)
Странно, что это не сделали раньше 🤔
Несколько лет гуляет так скажем.. (вообразим гипотетически конечно же, мы - порядочные господа🎩)
Проблема, которая решается в голове за 2 секунды действительно стоило написания и публикации статьи?
Вы конечно меня простите, но если это для вас открытие, добавьте хоть идейности и значимости в статью:
Какие лимиты на данный запрос после чего вам откажут мило в выдаче поисковых результатов?
Когда телеграм посчитает это злоупотреблением и что будет с акаунтом и после какого предупреждения читатели решившие повторить опыт будут "добрым" словом отзываться об этой статье?
Какой алгоритм на ваш взгляд используется в поиске юзернеймов?
А что если аккаунт без юзернейма впринципе?
Это весьма примитивные так-же вопросы, есть и более интересные и сложные - однако не всем такой опыт вообще нужен. Но минимально добавить полезности же не сложно, а то такое ощущение что открыли для себя один из методов работы поиска подстроки в форме поиска... Не сочтите за любые формы осуждения - но согласитесь добавив деталей, минимально о кейсе, эта статья будет куда полезнее читателям
Еще и gpg
Да я вижу вектор мыслей автора, собрать все pub-key ssh не великая проблема. (Конечно же gh-archive/gh-torrent не включает подобные данные).
Вроде не раз уже собиралось подобное по порту 22.
Но в контексте безопасности, безусловно есть "рычаги" влияния. Но в контексте концепции криптографии - приватный ключ должен быть в безопасности. Да великая проблема в том что мы не можем отслеживать попытки применения приват ключа. Но best practice гласит: используйте уникальную пару на сервис (ровно как и пароль), заменяйте регулярно пару (как гласит практика плановой смены "паролей", но в данном контексте ключ).
Есть ли смысл выставлять на всеобщее обозрение кейсы имеющие влияние на OA комьюнити? Сомневаюсь...
Шум и гам...
Оставлю это здесь https://trufflesecurity.com/blog/driftwood-know-if-private-keys-are-sensitive/
Ссылочку забыли
К сожалению почта на mail.ru + есть страничка в моем мире. Тырк, — «я все скажу»
— Логика элементарна, http://my.mail.ru/mail(bk|list|inbox)/username/
Где username — все до @, почтовый домен идет перед /username
99% выше изложенное = спс кэп.
Но проанализируйте теперь данные которые присутствую практически на всех страницах профиля мой мир, и откройте заявку на восстановление доступа к почтовому ящику, страничка где в саппорт заполняется анкетка. Обратите внимание на обязательные пункты в ней и на данные которые по дефолту содержит мой-мир.
з.ы. не забудем тот факт, что проверка идет по данным на которые регался почтовый акк… и унификацию данных профиля между сервисами мейл.ру.
Мб я просто не наше функции поменять к примеру имя только в моем мире, или эта фича появилась за последнее время. Но суть я надеюсь передал)