News for hackers. Stuff that matters.

alcroito

Cheers. I checked the updated steps.

This is still missing creating the `output/.postgres-data` dir, without which docker compose refuses to start.

After creating that manually, going to http://localhost/ shows a 403 Forbidden page, which makes you believe that something might have gone wrong.

This is before running `reddarchiver-builder python reddarc.py` to generate the necessary DB from the input data.

I tried spinning up the local approach with docker compose, but it fails.

There's no `.env.example` file to copy from. And even if the env vars are set manually, there are issues with the mentioned volumes not existing locally.

Seems like this needs more polish.

Re:The evolution of Lua, continued [pdf] on Tuesday October 07, 2025 @11:07AM (#45504071)
Anybody knows if there's a lua DAP (debugger) server in development by anyone?

Neovim lua has https://github.com/jbyuki/one-small-step-for-vimkind but it doesn't seem there's any DAP server for regular lua.

Re:Understanding the PURL Specification (Package URL) on Friday June 06, 2025 @04:55AM (#44198989)
I believe i was thinking of the comments at https://github.com/package-url/purl-spec/issues/59 but I see you've already replied there.
Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @06:12PM (#44196246)
Thanks for the links! I hope the proposal works out. I skimmed through the doc, and one thing i’d suggest is to consider using the CPS format rather than the ABOUT one for the metadata. The format is driven by Kitware, the developers of cmake, and thus if it’s contributed to them, a big chunk of the cpp ecosystem would get buy-in just because of the intertia of using cmake, and getting it for free with the tool.

https://cps-org.github.io/cps/overview.html

I’m not sure how I can help, but I’m open for discussion, because the company i work for is also interested in how to handle this well for our products.

Re:Understanding the PURL Specification (Package URL) on Thursday June 05, 2025 @02:14PM (#44194218)
I wish PURL proposed something sensible or at least usable for tracking C / C++ native libraries, that are NOT hosted on a registry like conan.io, or one of the linux distro registries, but is still (self-)hosted somewhere online.

For libraries that are hosted on `github`, there's at least the github type.

But there is no official `gitlab` or `git` type, and i've read comments that even the `github` type is considered a mistake.

One example of such a library could be a Qt or KDE / Plasma library.

They are hosted on their own forges, https://code.qt.io/ and https://invent.kde.org respectively.

So to the more knowledgeable people out there, what is the PURL way of identifying a C++ library like that?

Is `generic` type + vcs_url qualifier really the only way?

Right now it seems impossible to track vulnerabilities for such libraries with OSS / open tools, because none of the open tools or databases support a custom type or registry or ecosystem.

For example none of services here support some custom C++ ecosystem (putting aside conan):

https://docs.dependencytrack.org/analysis-types/known-vulner...

Same for https://docs.dependencytrack.org/datasources/osv/