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/
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.
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.
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.
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!
"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.
> * 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.
I'm working on a multisig sign-off solution, with the first use case being file downloads like GitHub releases authentication: https://github.com/asfaload/asfaload
I'm coming from F# and find rust a good compromise: great type safety (though I prefer the F# language) with an even better ecosystem. It can also generate decently sized statically compiled executables, useful for CLI tools, and the library code I wrote should be available to mobile apps (to be developed).
I have been using e/OS but moved away when an upgrade to the next version required to manually wipe the device. I could cope with the little inconveniences of a degoogled phone, but wiping the device myself following a unclear procedure was too much for me. My phone is not a hacking subject. It's a tool. Still, it worked reasonably well and I would have upgraded and kept using it if the upgrade had been easier.
I am on e/OS since 2021 with a FP3 and, for what is worth, I never had to reinstall, wipe or anything. My phone just had it's 5th birthday and it has been a single continuous set of updates.
I know the versions differ by model, so perhaps your model was not as well supported.
It was the gigaset gs190. I've used it quite some time with e/os, but one day the automatic updates stopped working and I discovered this reinstallation requirement.
Looks interesting. I'm currently using https://tuicr.dev/ , of which I like that the first screen it shows is the choice of commit range you want to review. Might be something to consider for deff?
Am I a fool to think that upcycled devices might not dent the sales of new devices, but would be used in new ways that would actually be positive for the vendor?
I think any effect on Samsung, positive or negative, would be negligible. It would help their PR slightly, but mostly among a relatively small part of their customer base.
On the negative side, it would probably have a minor impact on the number of new phones sold if old ones were able to be "refurbished" in this way. Again, probably not significant, but if it's even a penny cash flow negative, why invest their resources in it?
Overall the only significant gain to be made is the announcement because it can be spun and quoted to the average consumer as Samsung being more eco-friendly. It's akin to enabling consumerism, and consumers generally don't go to check if companies were telling the truth about this stuff.
reply