I am working on an open source project where users provide signatures of their projects artifacts (this is oversimplified for the sake of the discussion).
Started using Minisign as the signature scheme. But we're struggling to find a clean solution for users keys renewal, revocation and updated public key distribution. I thought foks might help for that but the examples don't seem to confirm this. Basically the question I need to answer is :how can users trusting an existing signing key also trust the new key replacing it? I hoped we might outsource this to foks, but I think I misunderstood foks in the first place.
This would be a great application for us! We are not exactly there yet, for reasons of privacy. Right now, there is no way for alice@host to allow unauthenticated users to view her profile. But we can definitely allow this on a host-by-host basis. With this small change, I think your application fits very naturally.
I wonder, what sort of interface is right for you? A library to compile against or a CLI app to shell out to? If a library, which languages?
Interesting!
We're at a very early stage of the implementation and develop in rust. We aim to provide multi-sig capabilities, as defined in a JSON file where the public keys of the signers can be found. If a signer looses a key, we want this 'signers' file to be updatable with the new key. We decided that signers can be humans of processes, so the keys are not an identity of a person, which might be an important detail. Currently, to update a signers file, other members of the multi-sig must sign the update. This works fine, but we are early enough in the project implementation to explore other approaches, hence my question.
We'd rather not shell out to a cli, and would preferably go with a lib or rest interface.
An attack that might be of concern with this configuration is the server suppressing updates to this JSON file, or showing different versions of the JSON file to different clients. What you're describing is pretty close to what FOKS is getting at with signature chains and Merkle Trees, but maybe it's overkill for this particular application.
I wonder if the policy you describe could be implemented as world-visible team with world-visible users. Others have commented on the need for something like this, so I think it should be pursued with high priority. What's slighlty fuzzy to me is how these totally world-viewable teams and users would interact with more closed-down users on other servers.
Although I didn't consider this attack possibility (thanks for raising it!), I think we are reasonably immune to it or able to detect it with the way we manipulate and store the JSON (though completely avoiding it seems not attainable, at one point the client has to trust the response it gets from a server, am I right? Otherwise I'm very interested in pointers to learn more!)
World visible teams and users might be a way to define our multi-sigs members. But we would still need a JSON file for others characteristics of the multi-sig. I'll keep an eye on foks as if it becomes a good fit, it might let us concentrate on our service and not on key management intricacies. My email is on my HN profile, in case you want to notify me of advancement fitting our use case.
Thanks for the pointers.
Are first glance, SSI seem to be mainly Blockchain based, which we diverted from to be able to have easy on premise deployments.
Verifiable credentials look interesting, but need to check usability. We want our solution to be very easy to use.
Did you get outside contributions yet?
I'm asking because it is dual licensed agpl and commercial (just like a recent project I'm working on), and am wondering how contributors react to the cla.
Btw I like your short and clear CLA!
Did you check the wording of the cla with a lawyer? In my project I wanted to replace the perpetual license granted by contributors by 'a license granted as long as the software is also proposed under the agpl', but that might make it too complicated to still keep it succinct and legally clear.
Yes we have had some PR and some active ones that we need to merge soon haha.
We have not had any concern about the CLA that we are aware of. It was important that we found a way to allow businesses to pay for something to fund the project while keeping it free for individual homelabbers so this was one effort in that regard.
I'm just starting a software project and, again, it is ambitious and somewhat complex (multi-sig signoff solution).
I envy people that can identify a simple project and execute it successfully.
But the challenge of building something more complex is what's interesting for me. And I'm not sure I would have more success with a simpler project, I'd get bored rapidly.
For me it helps to reflect on my desire to finish, which is mostly just a fragment of my day job. On my side projects, I can go as deep into the rabbit hole as I want, and enjoy the journey. Of course it feels great to publish something eventually, but the zen garden effect of just bike shedding to your hearts content is really something you shouldn’t dismiss immediately.
In case you're interested when you set up proper distribution, I'm working on an open source solution aiming to improve security of downloads from the internet. Our first step is maintaining a mirror of checksums published in GitHub releases at https://github.com/asfaload/checksums/. If you publish a checksums file in your releases it can automatically be mirrored.
The checksums mirror is not our end game, but it already protects against changes of released files from the time the mirror was taken.
For anyone interested: https://asfaload.com/asfald/
Having built a similar device, it appears that to give privacy to the person inside the bathroom, it is much better to have the music play outside. With music playing near to the "listener", the sounds coming from inside the room are much better covered.
What I did is ask Google Gemini to generate me a static site generator using data in a sqlite database. It's a Show HN I just submitted [1], and you can see the generated website at https://freshstuff.net/
Started using Minisign as the signature scheme. But we're struggling to find a clean solution for users keys renewal, revocation and updated public key distribution. I thought foks might help for that but the examples don't seem to confirm this. Basically the question I need to answer is :how can users trusting an existing signing key also trust the new key replacing it? I hoped we might outsource this to foks, but I think I misunderstood foks in the first place.