Forwarded from HN Best Comments
Re: At Amazon, some coders say their jobs have begun t...
To me it feels like part of the hype train, like crypto & VR.
I recently had the (dis)pleasure of fixing a bug in a codebase that was vibe coded.
It ends up being a collection of disorganized business problems converted into code, without any kind of structure.
Refinements are implemented as super-narrow patches, resulting in complex and unorganized code, whereas a human developer might take a step back to try and extract more common patterns.
And once you reach the limit of the context window you're essentially suck, as the LLM can no longer keep track of its patches.
English (or all spoken human language) is not precise enough to articulate what you want your code to do, and more importantly, a lot of time and experience precedes code that a senior developer writes.
If you want to have this senior developer 'vibe' code, then you'll need to have a way to be more precise in your prompts, and be able to articulate all learnings from your past mistakes and experience.
And that is incredibly heavy. Remember, this is opposite from answering 'why did you write it like this'. This is an endless list of items that say 'don't do this, but this, in this highly specific context'.
OptionOfT, 18 hours ago
To me it feels like part of the hype train, like crypto & VR.
I recently had the (dis)pleasure of fixing a bug in a codebase that was vibe coded.
It ends up being a collection of disorganized business problems converted into code, without any kind of structure.
Refinements are implemented as super-narrow patches, resulting in complex and unorganized code, whereas a human developer might take a step back to try and extract more common patterns.
And once you reach the limit of the context window you're essentially suck, as the LLM can no longer keep track of its patches.
English (or all spoken human language) is not precise enough to articulate what you want your code to do, and more importantly, a lot of time and experience precedes code that a senior developer writes.
If you want to have this senior developer 'vibe' code, then you'll need to have a way to be more precise in your prompts, and be able to articulate all learnings from your past mistakes and experience.
And that is incredibly heavy. Remember, this is opposite from answering 'why did you write it like this'. This is an endless list of items that say 'don't do this, but this, in this highly specific context'.
OptionOfT, 18 hours ago
Forwarded from HN Best Comments
Re: Frequent reauth doesn't make you more secure
Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
https://pages.nist.gov/800-63-3/sp800-63b.html
Or by Microsoft
> Password expiration requirements do more harm than good...
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide
But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).
montebicyclelo, 13 hours ago
Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
https://pages.nist.gov/800-63-3/sp800-63b.html
Or by Microsoft
> Password expiration requirements do more harm than good...
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide
But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).
montebicyclelo, 13 hours ago
Docs
Password policy recommendations - Microsoft 365 admin
Make your organization more secure against password attacks, and ban common passwords and enable risk-based multifactor authentication.
Forwarded from HN Best Comments
Re: OpenAI charges by the minute, so speed up your audio
With transcribing a talk by Andrej, you already picked the most challenging case possible, speed-wise. His natural talking speed is already >=1.5x that of a normal human. One of the people you absolutely have to set your YouTube speed back down to 1x when listening to follow what's going on.
In the idea of making more of an OpenAI minute, don't send it any silence.
E.g.
will cut the talk down from 39m31s to 31m34s, by replacing any silence (with a -50dB threshold) longer than 20ms by a 20ms pause. And to keep with the spirit of your post, I measured only that the input file got shorter, I didn't look at all at the quality of the transcription by feeding it the shorter version.
w-m, 1 day ago
With transcribing a talk by Andrej, you already picked the most challenging case possible, speed-wise. His natural talking speed is already >=1.5x that of a normal human. One of the people you absolutely have to set your YouTube speed back down to 1x when listening to follow what's going on.
In the idea of making more of an OpenAI minute, don't send it any silence.
E.g.
ffmpeg -i video-audio.m4a \
-af "silenceremove=start_periods=1:start_duration=0:start_threshold=-50dB:\
stop_periods=-1:stop_duration=0.02:stop_threshold=-50dB,\
apad=pad_dur=0.02" \
-c:a aac -b:a 128k output_minpause.m4a -y
will cut the talk down from 39m31s to 31m34s, by replacing any silence (with a -50dB threshold) longer than 20ms by a 20ms pause. And to keep with the spirit of your post, I measured only that the input file got shorter, I didn't look at all at the quality of the transcription by feeding it the shorter version.
w-m, 1 day ago
Forwarded from HN Best Comments
Re: Ask HN: The government of my country blocked VPN access. What should I use?
Hello! I've got experience working on censorship circumvention for a major VPN provider (in the early 2020s).
- First things first, you have to get your hands on actual VPN software and configs. Many providers who are aware of VPN censorship and cater to these locales distribute their VPNs through hard-to-block channels and in obfuscated packages. S3 is a popular option but by no means the only one, and some VPN providers partner with local orgs who can figure out the safest and most efficient ways to distribute a VPN package in countries at risk of censorship or undergoing censorship.
- Once you've got the software, you should try to use it with an obfuscation layer.
Obfs4proxy is a popular tool here, and relies on a pre-shared key to make traffic look like nothing special. IIRC it also hides the VPN handshake. This isn't a perfectly secure model, but it's good enough to defeat most DPI setups.
Another option is Shapeshifter, from Operator (https://github.com/OperatorFoundation). Or, in general, anything that uses pluggable transports. While it's a niche technology, it's quite useful in your case.
In both cases, the VPN provider must provide support for these protocols.
- The toughest step long term is not getting caught using a VPN. By its nature, long-term statistical analysis will often reveal a VPN connection regardless of obfuscation and masking (and this approach can be cheaper to support than DPI by a state actor). I don't know the situation on the ground in Indonesia, so I won't speculate about what the best way to avoid this would be, long-term.
I will endorse Mullvad as a trustworthy and technically competent VPN provider in this niche (n.b., I do not work for them, nor have I worked for them; they were a competitor to my employer and we always respected their approach to the space).
_verandaguy, 3 hours ago
Hello! I've got experience working on censorship circumvention for a major VPN provider (in the early 2020s).
- First things first, you have to get your hands on actual VPN software and configs. Many providers who are aware of VPN censorship and cater to these locales distribute their VPNs through hard-to-block channels and in obfuscated packages. S3 is a popular option but by no means the only one, and some VPN providers partner with local orgs who can figure out the safest and most efficient ways to distribute a VPN package in countries at risk of censorship or undergoing censorship.
- Once you've got the software, you should try to use it with an obfuscation layer.
Obfs4proxy is a popular tool here, and relies on a pre-shared key to make traffic look like nothing special. IIRC it also hides the VPN handshake. This isn't a perfectly secure model, but it's good enough to defeat most DPI setups.
Another option is Shapeshifter, from Operator (https://github.com/OperatorFoundation). Or, in general, anything that uses pluggable transports. While it's a niche technology, it's quite useful in your case.
In both cases, the VPN provider must provide support for these protocols.
- The toughest step long term is not getting caught using a VPN. By its nature, long-term statistical analysis will often reveal a VPN connection regardless of obfuscation and masking (and this approach can be cheaper to support than DPI by a state actor). I don't know the situation on the ground in Indonesia, so I won't speculate about what the best way to avoid this would be, long-term.
I will endorse Mullvad as a trustworthy and technically competent VPN provider in this niche (n.b., I do not work for them, nor have I worked for them; they were a competitor to my employer and we always respected their approach to the space).
_verandaguy, 3 hours ago
GitHub
Operator Foundation
Operator is a non-profit that makes useable tools to help people around the world with censorship, security, and privacy. - Operator Foundation
Forwarded from HN Best Comments
Re: Next.js is infuriating
I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts.
Next.js is easily the worst technology I've ever used.
YuukiRey, 9 hours ago
I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.
In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts.
Next.js is easily the worst technology I've ever used.
YuukiRey, 9 hours ago
Forwarded from HN Best Comments
Re: Why Self-Host?
"start self-hosting more of your personal services."
I would make the case that you should also self host more as a small Software/SAAS business and it is not quite the boogeyman that a lot of cloud vendors want you to think.
Here is why. Most software projects/businesses don't require the scale and complexity for which you truly need the cloud vendors and their expertise. For example, you don't need Vercel to deploy NextJS or whatever static website or even netlify. You can setup Nginx or Caddy (my favorite) on a simple VPS with Ubuntu etc and boom. For majority of projects, that will do.
90%+ of projects can be self hosted with the following:
- A well hardened VPS server with good security controls. Plenty of good articles online on how to do the most important things (remove root login, ssh should only be key based etc).
- Setup a reverse proxy like Caddy (my favorite) or Nginx etc. Boom. Static files can now be served. Static websites can be served. No need for CDN etc unless you are talking about millions of requests per day.
- Setup your backend/API with something simple like supervisor or even the native systemd.
- The same Reverse proxy can also forward requests to backend and other services as needed. Not that hard.
- Self host a mysql/postgres database and setup the right security controls.
- Most importantly: Setup backups for everything using a script/cron and test them periodically.
- IF you really want to feel safe against DOS/DDOS etc, add cloudflare in front of everything.
So you end up with:
Cloudflare/DNS=>Reverse Proxy (Caddy/Nginx)=>Your App.
- You want to deploy ? Git pull should do it for most projects like PHP etc. If you have to rebuild binary, it will be another step but possible.
You don't need Docker or containers. They can help but not needed for small to even mid sized projects.
Yes, you can claim that a lot of these things are hard and I would say they are not that hard. Majority of projects don't need the web scale or whatever.
codegeek, 2 days ago
"start self-hosting more of your personal services."
I would make the case that you should also self host more as a small Software/SAAS business and it is not quite the boogeyman that a lot of cloud vendors want you to think.
Here is why. Most software projects/businesses don't require the scale and complexity for which you truly need the cloud vendors and their expertise. For example, you don't need Vercel to deploy NextJS or whatever static website or even netlify. You can setup Nginx or Caddy (my favorite) on a simple VPS with Ubuntu etc and boom. For majority of projects, that will do.
90%+ of projects can be self hosted with the following:
- A well hardened VPS server with good security controls. Plenty of good articles online on how to do the most important things (remove root login, ssh should only be key based etc).
- Setup a reverse proxy like Caddy (my favorite) or Nginx etc. Boom. Static files can now be served. Static websites can be served. No need for CDN etc unless you are talking about millions of requests per day.
- Setup your backend/API with something simple like supervisor or even the native systemd.
- The same Reverse proxy can also forward requests to backend and other services as needed. Not that hard.
- Self host a mysql/postgres database and setup the right security controls.
- Most importantly: Setup backups for everything using a script/cron and test them periodically.
- IF you really want to feel safe against DOS/DDOS etc, add cloudflare in front of everything.
So you end up with:
Cloudflare/DNS=>Reverse Proxy (Caddy/Nginx)=>Your App.
- You want to deploy ? Git pull should do it for most projects like PHP etc. If you have to rebuild binary, it will be another step but possible.
You don't need Docker or containers. They can help but not needed for small to even mid sized projects.
Yes, you can claim that a lot of these things are hard and I would say they are not that hard. Majority of projects don't need the web scale or whatever.
codegeek, 2 days ago
Forwarded from HN Best Comments
Re: Uv is the best thing to happen to the Python ecosystem in a decade
For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script:
The script now works like a standalone executable, and uv will magically install and use the specified modules.
LeoPanthera, 8 hours ago
For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script:
#!/usr/bin/env -S uv run --script
# /// script
# requires-python = ">=3.11"
# dependencies = [ "modules", "here" ]
# ///
The script now works like a standalone executable, and uv will magically install and use the specified modules.
LeoPanthera, 8 hours ago
Forwarded from HN Best Comments
Re: NPM flooded with malicious packages downloaded more than 86k times
Here's my `npm` command these days.
It reduces the attack surface drastically.
Ref: https://ashishb.net/programming/run-tools-inside-docker/
ashishb, 2 days ago
Here's my `npm` command these days.
It reduces the attack surface drastically.
alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm'
- No access to my env vars
- No access to anything outside my current directory (usually a JS project).
- No access to my .bashrc or other files.
Ref: https://ashishb.net/programming/run-tools-inside-docker/
ashishb, 2 days ago
ashishb.net
To keep your machine secure, run third-party tools inside Docker
Always run third-party CLI tools inside Docker
Forwarded from HN Best Comments
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
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
Zeroclarkthirty
SQLite: understanding and fixing "database is locked"
Clark Kampfe - zeroclarkthirty.com
Forwarded from Too Long, Did Read
Что таит гит?
https://medium.com/@sharon.brizinov/how-i-made-64k-from-deleted-files-a-bug-bounty-story-c5bd3a6f5f9b
Прочитал супер крутую историю одного bug bounty hunter'a про почти полностью автоматизированный пайплайн, который позволил ему просканировать git-репозитории кучи компаний и найти в них секреты == получить вознаграждение за найденные уязвимости.
Всего он настриг $64k с помощью своего инструмента.
Автор очень подробно рассказывает про то, как устроено хранение файлов, коммитов и метаданных в гите - советую почитать!
Перескажу только самый сок, который и позволил ему получить столько денег: что происходит с файлом, когда его удаляют из гита [из текущей версии / из ветки ...]
Как работает 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" стартапа - мне даже не пришлось никакие удаленные файлы восстанавливать )
Думаю заняться созданием похожего полуавтоматического пайплайна, но с другой аудиторией и немного другими классами уязвимостей.
Как будут какие-то результаты - расскажу!
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" стартапа - мне даже не пришлось никакие удаленные файлы восстанавливать )
Думаю заняться созданием похожего полуавтоматического пайплайна, но с другой аудиторией и немного другими классами уязвимостей.
Как будут какие-то результаты - расскажу!
Medium
How I made $64k from deleted files — a bug bounty story
TL;DR — I built an automation that cloned and scanned tens of thousands of public GitHub repos for leaked secrets. For each repository I…
Forwarded from HN Best Comments
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
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
GitHub
GitHub - psanford/sqlite3vfs: Go sqlite3 vfs
Go sqlite3 vfs. Contribute to psanford/sqlite3vfs development by creating an account on GitHub.