News for hackers. Stuff that matters.

mrnaif

Re:Forgejo <=16.0.3 Critical RCE on Sunday September 13, 2026 @07:48AM (#49682927)
Our forgejo instance got affected by this. I saw the news and thought we don't need to upgrade (yet), as registration is closed for new users, and users having access is only those we control. As it turns out, when in app.ini we have DISABLE_REGISTRATION = true, it doesn't actually disable registration... Even though no sign in or sign up form was rendered, the attacker used openid registration

as in our config I had

[openid] ENABLE_OPENID_SIGNIN = true ENABLE_OPENID_SIGNUP = true

attacker created a fake openid server, registered this way, created like 100+ repositories, was able to create a superadmin account on forgejo, mint tokens, execute commands from the runner trying to escalate permissions - either via git hooks, or in runner itself. Luckily our runner was running on a separate isolated server, but potential damage could have been much worse.

So yeah, everyone update ASAP if you don't want to spend half a day fixing the consequences (:

Also added html reports output https://github.com/MrNaif2018/changelog-checker/blob/master/...

HN, looking forward to your feedback!

Show HN: Changelog Checker – Aggregate and Inspect Your Dependency Changelogs

https://github.com/MrNaif2018/changelog-checker/blob/master/README.md

So recently I was updating my uv lockfile via uv sync -U, and it had more than 70 dependency updates. Usually I check the changelogs of all updated packages just to be sure that nothing is broken (because semver is semver, but well, not always followed) So instead of googling a package name's github, finding a changelog, which is sometimes in github releases, sometimes in CHANGELOG sometimes in...

( Read More... | 1 comment | 3 points | on HN )
I would like to show my new Python library: universalasync. It helps library maintainers to create only asynchronous version of their libs, and synchronous version will be created automatically, so that users could use it in their sync and async apps interchangeably.

For example, when running inside a sync function, you could call obj.method(), but when running inside an async function you could also call await obj.method()

So there is no need to create async_* variants of your functions, or use other methods of creating sync versions (for example in my another library some time ago I was just removing async and await and publishing this as a separate package).

The library has 0 dependencies of course, it wraps all public methods of a class to it's implementation. It basically does what you would have done if you needed to run a coroutine from your sync code, but automatically.

API reference can be found here: https://universalasync.bitcartcc.com/en/latest/api.html

Any feedback, testing and bugs found welcome!

Hello! BitcartCC (https://bitcartcc.com) is my project I wanted to share with HN for a long time. It is an opensource self-hosted all-in-one (as we call it) solution for cryptocurrencies.

Why did we call it so? Because we target different audiencies and try to provide each of them the right tools. For merchants we provide ready admin panel where they can manage their products, invoices, checkout settings and postprocessing rules. The admin panel contains a checkout page which can be loaded from another site via iframe. The checkout page from admin is used by external integration plugins for woocommerce, whmcs and others (to don't reinvent the wheel each time). But if merchants don't have any coding skills they can (and by default it is included) enable ready store, which is a bit basic, but displays products added in admin panel and contains each own checkout page. I think it can be used even in offline store when i.e. installed on a tablet (as a PWA app)

For developers we provide some useful tools in building their apps. We provide python SDK and Merchants API. But first let me show how it all works. You can check the structure here: https://docs.bitcartcc.com/development/architecture Basically the whole app consists of "layers", where the lower level is, the harder it is to use it, but the more features it can allow. Upper layers build on lower ones and specialize on some specific things. At the core of the whole ecosystem are BitcartCC core daemons: those are wrappers around electrum wallet's daemon extending it with new features like wallet loading on the fly, better exception messages and new commands, as well as support for different methods of delivering event notifications (used to track payments): polling and websockets.

Those daemons expose all CLI commands electrum provides plus the event system via JSON-RPC 2.0 interface. Those daemons can be accessed via any language (sending HTTP POST request via json-rpc), or via python SDK which basically implements all the features required for ease of use (like in case of exception, it looks up exception code from the daemon exception spec and dynamically creates needed exception object).

So SDK and daemons are considered to be used for any type of apps, as you can send, receive payments, watch for address, get transaction info, connect to lightning network nodes and so on.

Then there is Merchants API, which is designed to be used in any kind of store. It implements all CRUD editing of objects like stores, products, wallets, invoices, discounts, and so on. Also it implements the actual watch for payments system. Background worker connects via websocket to all enabled coin daemons, and listens for certain events, updating invoice statuses in database when needed. It's use case is for custom integrations in complex stores, or for basically any merchant-like programmatic usage. And in the end, admin panel and store just calls Merchants API.

The whole approach is using like at maximum 2 gb of disk space, not using a full node. But it is still considered secure because of electrum wallet's networking model-it uses Simple Payment Verification, connecting to many servers and validating the right state of the blockchain.

And a very important step-deployment. You can see demo versions of components deployed at our server, but we recommend all users to self-host their instance. Admin panel: https://admin.bitcartcc.com Store: https://store.bitcartcc.com Merchants API: https://api.bitcartcc.com SDK docs: https://sdk.bitcartcc.com

We use docker for deployment. Each service is packaged in a container, and users can select which parts to install: only daemons, Merchants API stack, only admin and store, or everything in once. It is achieved via dynamic generation of docker-compose.yml files based on environment variables.

So that's a short description of the project. We'd love to get some feedback about how can we improve, both code-wise and ideas-wise. The source code for all repos is in https://github.com/bitcartcc. Thank you!