Неплохо для начала самостоятельных изысканий. Мысли и желания идут в верном направлении. Если не хотите тратить много времени, то вот вам ключевое слово — DDD.
Пару раз был на докладах по Тарантулу, и каждый раз попадал на какой-то, простите, маркетинговый булшит.
А вот это — прям офигительно. Лучшее, что я читал по СУБД. Обожаю такие доклады, в которых люди могут сложные вещи объяснить простым человеческим языком. Я ничего не понял, но ты достучался до моего сердца, бро. И вот такие именно доклады, а не рекламные, побуждают к использованию продукта.
Если внимательно прочитать пост, то можно найти фразу
Это по сути интерфейс управления процессом проведения CTF, не больше.
Задания — любые: теоретические, практические, метафизические. Но вы их сами должны создавать и хостить. А эта штука помогает вам именно в организации соревнования.
Как минимум описание «что? зачем? когда нельзя использовать? когда нужно?».
Конечно, именно о такой документации я и говорю. Держим в коде, экспортируем куда угодно при помощи всяких клёвых утилит, многократно упомянутых выше.
… Выложите новый метод на боевой сервер — просто скопируете документацию из задачи в ваше хранилище документации
… Задача на разработку API в jira/redmine — ну никак не источник документации ее вообще потом могут не найти, да и искать не нужно.
Вы начинаете путаться в показаниях.
Если так приходится делать — вы либо теряете обратную совместимость, либо делаете новую версию...
Стоп, я не говорил о BC breaking changes, я говорил лишь о доработке документации: забыли описать важную фичу, описали что-то недостаточно ясно, да просто орфографические и пунктуационные ошибки. Вы описываете какой-то идеальный кейс, когда ничего этого никогда не происходит.
Нет, подождите. Я не знаю, о какой разметке вы говорите (у нас, например, это просто часть апи: нельзя выкатить незадокументированный метод), но дело даже не в этом. В любом случае же нужны какие-то усилия на документирование. И если я правильно понял (а я не исключаю, что понял неправильно), то вы предлагаете копировать документацию из одного места в другое («Выложите новый метод на боевой сервер — просто скопируете документацию из задачи в ваше хранилище документации.»). И теперь у вас два источника одной информации. Проблема в том, что документацию часто приходится дополнять, поправлять. Теперь на каждую правку нужно делать ещё и копирование, о котором забыть гораздо проще.
В целом то, что вы описываете, больше похоже на «сначала досканально спроектируйте метод апи, включая техническое проектирование, а затем — реализуйте». То есть, на этапе проектирования вы уже его документируете. Это всё правильно, да. Но что мешает затем документацию закрепить за методом и не копипастить повсюду? Сваггер и ему подобные инструменты как раз позволяют это сделать.
Если вы серьёзно спрашиваете, то на платформе H1 есть как открытые BB, так и закрытые. Закрытые доступны только некоторым участникам, у которых уже есть определённый уровень репутации, то есть, они до этого уже много и успешно репортили. Есть программы, в которые вообще только лично приглашают. Это позволяет значительно повысить показатель качество/количество, который у открытых программ часто низок из-за шума, создаваемого всякого рода «индусами» и прочими скрипткиддисами.
Это посты от 3 мая, то есть, либо незадолго до публичного раскрытия, либо сразу после него (не помню точное время). Больше похоже на попытку перебдеть. Текущий policy-конфиг работает для всех известных на данный момент PoC. Не могу говорить с полной уверенностью, но ощущение, что часть строк там ничего не делает. Были бы пруфы, можно было бы что-то обсуждать.
Есть источник? Там же наверняка есть эксплойты к этим дополнительным паттернам, я бы проверил. Мне кажется, на деле они покрываются теми, что указаны на imagetragick.com.
Неплохо для начала самостоятельных изысканий. Мысли и желания идут в верном направлении. Если не хотите тратить много времени, то вот вам ключевое слово — DDD.
Пару раз был на докладах по Тарантулу, и каждый раз попадал на какой-то, простите, маркетинговый булшит.
А вот это — прям офигительно. Лучшее, что я читал по СУБД. Обожаю такие доклады, в которых люди могут сложные вещи объяснить простым человеческим языком.
Я ничего не понял, но ты достучался до моего сердца, бро. И вот такие именно доклады, а не рекламные, побуждают к использованию продукта.Либо я вас не понимаю, либо вы не понимаете, что такое CTF. У меня ощущение, что вы путаете CTF со спортивным программированием.
Если внимательно прочитать пост, то можно найти фразу
Задания — любые: теоретические, практические, метафизические. Но вы их сами должны создавать и хостить. А эта штука помогает вам именно в организации соревнования.
Конечно, именно о такой документации я и говорю. Держим в коде, экспортируем куда угодно при помощи всяких клёвых утилит, многократно упомянутых выше.
Вы начинаете путаться в показаниях.
Стоп, я не говорил о BC breaking changes, я говорил лишь о доработке документации: забыли описать важную фичу, описали что-то недостаточно ясно, да просто орфографические и пунктуационные ошибки. Вы описываете какой-то идеальный кейс, когда ничего этого никогда не происходит.
Нет, подождите. Я не знаю, о какой разметке вы говорите (у нас, например, это просто часть апи: нельзя выкатить незадокументированный метод), но дело даже не в этом. В любом случае же нужны какие-то усилия на документирование. И если я правильно понял (а я не исключаю, что понял неправильно), то вы предлагаете копировать документацию из одного места в другое («Выложите новый метод на боевой сервер — просто скопируете документацию из задачи в ваше хранилище документации.»). И теперь у вас два источника одной информации. Проблема в том, что документацию часто приходится дополнять, поправлять. Теперь на каждую правку нужно делать ещё и копирование, о котором забыть гораздо проще.
В целом то, что вы описываете, больше похоже на «сначала досканально спроектируйте метод апи, включая техническое проектирование, а затем — реализуйте». То есть, на этапе проектирования вы уже его документируете. Это всё правильно, да. Но что мешает затем документацию закрепить за методом и не копипастить повсюду? Сваггер и ему подобные инструменты как раз позволяют это сделать.
Вот тут можно чуть подробнее? О какой именно поддержке Сваггера вы говорите?
Жестоко!
На imagetragick.com обновили рекомендуемый policy.xml, он теперь что-то среднее из тех, которые по вашим ссылкам. Обновил пост.
Это посты от 3 мая, то есть, либо незадолго до публичного раскрытия, либо сразу после него (не помню точное время). Больше похоже на попытку перебдеть. Текущий policy-конфиг работает для всех известных на данный момент PoC. Не могу говорить с полной уверенностью, но ощущение, что часть строк там ничего не делает. Были бы пруфы, можно было бы что-то обсуждать.
Есть источник? Там же наверняка есть эксплойты к этим дополнительным паттернам, я бы проверил. Мне кажется, на деле они покрываются теми, что указаны на imagetragick.com.
Выложили обещанные PoC — https://github.com/ImageTragick/PoCs + там же простой шелл-скрипт для локальной проверки.
Добавил в пост, спасибо.