Re: SQLite concurrency and why you should care about it

In SQLite, transactions by default start in “deferred” mode. This means they do not take a write lock until they attempt to perform a write.

You get SQLITE_BUSY when transaction #1 starts in read mode, transaction #2 starts in write mode, and then transaction #1 attempts to upgrade from read to write mode while transaction #2 still holds the write lock.

The fix is to set a busy_timeout and to begin any transaction that does a write (any write, even if it is not the first operation in the transaction) in “immediate” mode rather than “deferred” mode.

https://zeroclarkthirty.com/2024-10-19-sqlite-database-is-lo...

asa400, 7 hours ago

Что таит гит?

https://medium.com/@sharon.brizinov/how-i-made-64k-from-deleted-files-a-bug-bounty-story-c5bd3a6f5f9b

Прочитал супер крутую историю одного bug bounty hunter'a про почти полностью автоматизированный пайплайн, который позволил ему просканировать git-репозитории кучи компаний и найти в них секреты == получить вознаграждение за найденные уязвимости.

Всего он настриг $64k с помощью своего инструмента.

Автор очень подробно рассказывает про то, как устроено хранение файлов, коммитов и метаданных в гите - советую почитать!
Перескажу только самый сок, который и позволил ему получить столько денег: что происходит с файлом, когда его удаляют из гита [из текущей версии / из ветки ...]

The juice — so how do we get all deleted files?:

- Restored deleted files by diffing parent-child commits.
- Unpack all .pack files using git unpack-objects < .git/objects/pack/pack-<SHA>.pack
- Find dangling objects using git fsck — full — unreachable — dangling

Как работает git rm?

Дело в том, что история гита неизменяема, — каждый коммит содержит в себе полный слепок* изменений файловой системы на момент создания, включая референсы — ссылки на файлы, в том числе и удаленные.
Даже те удаленные файлы, на которые референсов вообще нет, остаются в служебных файлах гита на 2 недели.

Получается, что если один раз неосторожно закоммитить условный .env или скрипт с закомменченным API-ключом - он останется в истории навсегда*, и его надо вычищать специальным образом. А многие не знают про это и не вычищают - в текущей версии лишних файлов нет, ну и хорошо.

Помимо этого, бывают кейсы, когда в .gitignore забывают добавить всякие служебные директории или файлы, например .pyc файлы, в которых в перемешку с бинарным кодом могут остаться секреты.


Чтобы по-настоящему очистить историю репозитория или удалить оттуда файл, нужно использовать специальные тулзы вроде git filter-branch, git-filter-repo, либо вручную rebas`ить и прунить мусор - задача, судя по всему, нетривиальная.

Процесс поиска секретов

1. Автор попарсил открытые списки bug bounty програм и составил список из кучи компаний
2. Для каждой компании нашел +- все ее публичные репозитории
3. С помощью алгоритма из цитаты выше восстановил все удаленные файлы
4. С помощью TruffleHog прошелся по каждому файлу и поискал там секреты, а также проверил, настоящие ли они и активны ли до сих пор (за истекшие ключи денег не платят)
5. Настроил автоматические уведомления о найденных живых ключах в тг

Суммарно секретов, найденных с помощью этого алгоритма, хватило на $64.350 в вознаграждениях - неплохой результат для автоматизированного инструмента.

Самые "дорогие" ключи, кстати, это GCP (Google Cloud Platform) и продовые AWS-токены - найдя такой ключ, можно сделать с инфраструктурой компании много всего (если не вообще все).
За каждый найденный ключ из этой категории, со слов автора, заплатили $5k–$15k.

Мораль

1. Автоматические тулзы для поиска уязвимостей, секретов или незакрытых эндпоинтов вовсю применяются в реальном мире.
Аргументы "да кто меня будет взламывать" медленно теряют свой смысл (особенно, если вам / компании есть, что терять)
2. Будьте осторожны с вашими репозиториями: все, что вы туда закоммитите, останется там +- навсегда, если не проводить гигиеническую чистку.

Ну и еще добавлю, что недавно я тоже нашел AWS-секрет в коде одного "vibecoded" стартапа - мне даже не пришлось никакие удаленные файлы восстанавливать )

Думаю заняться созданием похожего полуавтоматического пайплайна, но с другой аудиторией и немного другими классами уязвимостей.
Как будут какие-то результаты - расскажу!

Re: Litestream VFS

Oh hey this is using my go sqlite vfs module[0]. I love it when I find out some code I wrote is useful to others!

[0]: https://github.com/psanford/sqlite3vfs

psanford, 2 days ago

Re: Ask HN: How can I get better at using AI for programming?

Hey, Boris from the Claude Code team here. A few tips:

1. If there is anything Claude tends to repeatedly get wrong, not understand, or spend lots of tokens on, put it in your CLAUDE.md. Claude automatically reads this file and it’s a great way to avoid repeating yourself. I add to my team’s CLAUDE.md multiple times a week.

2. Use Plan mode (press shift-tab 2x). Go back and forth with Claude until you like the plan before you let Claude execute. This easily 2-3x’s results for harder tasks.

3. Give the model a way to check its work. For svelte, consider using the Puppeteer MCP server and tell Claude to check its work in the browser. This is another 2-3x.

4. Use Opus 4.5. It’s a step change from Sonnet 4.5 and earlier models.

Hope that helps!

bcherny, 4 hours ago

remotion prompt

https://gist.github.com/JonnyBurger/5b801182176f1b76447901fbeb5a84ac

Re: The three pillars of JavaScript bloat

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc.

People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependency-heavy projects.

auxiliarymoose, 19 hours ago

Re: I put all 8,642 Spanish laws in Git – every reform is a commit

I built a pipeline that converts all Spanish state legislation into version-controlled Markdown. Each law is a file, each reform is a real git commit with the historical date. 8,642 laws, 27,866 commits.

The idea: legislation is just patches on patches on patches. Git already solves this. Instead of reading "strike paragraph 3 and replace with...", you get an actual diff.

The repo is the product. Browse any law, git log to see its full reform history, git diff to see exactly what changed.

Built the pipeline in ~4 hours with Claude Code. Source is BOE (Spain's official gazette) consolidated legislation API.

Exploring whether there's a business here — structured legislation API for legaltech/compliance, or just a useful open dataset. Curious what HN would build with this data.

enriquelop, 4 hours ago

Re: 5x5 Pixel font for tiny screens

1x5 can also work if you take advantage of subpixel rendering https://www.msarnoff.org/millitext/

FelipeCortez, 5 hours ago