For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | raphinou's commentsregister

What solution do you use for declarative deployments? Last time I looked there was no default option?

Look into https://gitlab.com/r3j0/incus-compose, it just published its first beta but it nicely gaps some of Docker Compose into Incus-land

I use my own solution (set of bash scripts) on top of IncusOS support for declarative files.

From my understanding the checkmarx attack could have been prevented by the asfaload project I'm working on. See https://github.com/asfaload/asfaload

It is:

- open source

- accountless(keys are identity)

- using a public git backend making it easily auditable

- easy to self host, meaning you can easily deploy it internally

- multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected

- validating a download transparantly to the user, which only requires the download url, contrary to sigstore


Am I missing something? I'm genuinely surprised it was not deployed from the start on a dedicated server. Don't you make a cost analysis before deploy? And if the cost analysis was ok at initial deploy, why wait to have such a difference in cost before migrating? How much money goes wasted in such situations?

Managed services have value. It's less to set up, less to maintain, and less worrying about waking up at 3am when something breaks.

I've spent time eating the costs of things like DigitalOcean or SaaS products because my time is better spent growing my revenue than reducing infrastructure costs. But at some point, costs can grow large enough that's it's worthwhile to shift focus to reducing infrastructure spend.


Working on Asfaload, a multisig sign-off solution applied to release artifacts authentication.

It is:

- open source

- accountless(keys are identity)

- using a public git backend making it easily auditable

- easy to self host, meaning you can easily deploy it internally

- multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected

- validating a download transparantly to the user, which only requires the download url, contrary to sigstore

Nearing Alpha release stage.

Code at https://github.com/asfaload/asfaload Info at https://asfaload.com/


One (amongst other) big problem with current software supply chain is that a lot of tools and dependencies are downloaded (eg from GitHub releases) without any validation that it was published by the expected author. That's why I'm working on an open source, auditable, accountless, self hostable, multi sig file authentication solution. The multi sig approach can protect against axios-like breaches. If this is of interest to you, take a look at https://asfaload.com/


I’m maybe not understanding here, but isn’t it the point of release attestations (to authenticate that the release was produced by the authors)?

[0] https://docs.github.com/en/actions/how-tos/secure-your-work/...


Artifact attestation are indeed another solution based on https://www.sigstore.dev/ . I still think Asfaload is a good alternative, making different choices than sigstore:

- Asfaload is accountless(keys are identity) while sigstore relies on openid connect[1], which will tie most user to a mega corp

- Asfaload ' backend is a public git, making it easily auditable

- Asfaload will be easy to self host, meaning you can easily deploy it internally

- Asfaload is multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected

- validating a download is transparant to the user, which only requires the download url, contrary to sigstore [2]

So Asfaload is not the only solution, but I think it has some unique characteristics that make it worth evaluating.

1:https://docs.sigstore.dev/about/security/

2: https://docs.sigstore.dev/cosign/verifying/verify/


The problem is nobody checks.

All the axios releases had attestations except for the compromised one. npm installed it anyway.


Yes, that's why I aim to make the checks transparant to the user. You only need to provide the download url for the authentication to take place. I really need to record a small demo of it.


Overall I believe this is the right approach and something like this is what's required. I can't see any code or your product though so I'm not sure what to make of it.


Here's the GitHub repo of the backend code: https://github.com/asfaload/asfaload

There's also a spec of the approach at https://github.com/asfaload/spec

I'm looking for early testers, let me know if you are interested to test it !


> without any validation that it was published by the expected author

SPOF. I'd suggest use automatic tools to audit every line of code no matter who the author is.


Just like the title


12 minute read without a clear indication of what it’s about. No thanks.


I'm working on a multi signature solution that helps to detect unauthorized releases in the case of an account hijack. It is open source, self hostable, accountless and I am looking for feedback!

Website: https://asfaload.com/

GitHub:https://github.com/asfaload/asfaload

Spec: https://github.com/asfaload/spec


In my project's readme I put this text:

   "There is no commit by an agent user, for two reasons:

    * If an agent commits locally during development, the code is reviewed and often thoroughly modified and rearranged by a human.
    * I don't want to push unreviewed code to the repo, so I have set up a git hook refusing to push commits done by an LLM agent."

It's not that I want to hide the use of llms, I just modified code a lot before pushing, which led me to this approach. As llms improve, I might have to change this though.

Interested to read opinions on this approach.


> * I don't want to push unreviewed code to the repo, so I have set up a git hook refusing to push commits done by an LLM agent."

Seems... Not that useful?

Why would someone make commits in your local projects without you knowing about it? That git hook only works on your own machine, so you're trying to prevent yourself from pushing code you haven't reviewed, but the only way that can happen is if you use an agent locally that also make commits, and you aren't aware of it?

I'm not sure how you'd end up in that situation, unless you have LLMs running autonomously on your computer that you don't have actual runtime insights into? Which seems like it'd be a way bigger problem than "code I didn't reviewed was pushed".


The agents run in a container and have an other git identity configured. It happens that agents commit code and I don't want to push it accidentally from outside the container, which is where I work.


I'm working on a multi signature system for file authentication that can detect unauthorized file publications. It is self-funded, open source, auditable, self hostable, accountless. I'm looking for testers and feedback, don't hesitate to contact me if interested. More info at https://asfaload.com/


I've installed https://getaurora.dev/en/, another atomic Linux distro, for a non technical user and find it really good. I've read arguments that its architecture was better than kalpa, but I don't find it back and I have no sufficient knowledge or experience of both to have an opinion.


For the uninitiated, it’s another UniversalBlue project just like the popular Bazzite. It focuses on a general computing usecase instead of gaming.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You