I think https://keyoxide.org provides some kind of middle ground for verifying identity here. The identity there is not meant to be real life names but rather a collection of all social profiles bi-directionally linked together with OpenPGP signatures.
This again verifies identities and in no way software. What's the point?
If you decide to trust "the Python Foundation", what does this key do for you if you're already downloading binaries from python.org? And if you don't, how much does the fact that they have a key help you? Anyone can get a key.
Hackers can compromise python.org and sign stuff with a key advertised there. But the site is just one point. It's much harder to hack python.org and also their GitHub and Twitter account (and DNS and dozens of other supported services).
Keyoxide makes the signing key links on multiple sites thus raising a bar for accepting fake key. It's not a silver bullet obviously. Just makes the attack harder to pull and is machine readable (instead of making humans check the keys).
I commented elsewhere so I sound like I am trying to push it. This book does it. I speak passionately about this because video tutorials just don’t do it for me. And you asked for a book but the other comment is a video. When you google Blender books it’s mostly people asking and people answering with videos references : https://www.blendersecrets.org/book
Greatly appreciate it! I don't know why but book format is the one I like best, maybe it's a mix of learning at my own speed and at the same time something tangible that I can mark in various ways.
I don't have a script. I submitted patches to zbar and added instructions to the Arch Wiki once the updated version of zbar landed in the repositories.
Yeah. Actually ssh agent speaks PKCS#11 (both client and server) so it's possible to interface with the hardware token quite easily. I'm using that to store my client key in TPM for example.
> It would be so much better if standard practice was to generate and store the private key on a smartcard or the TPM, so that the only file a clueless/careless developer could upload would be a stub.
Yep. Especially given that basically all modern laptops (and some PCs) ship with TPMs and ssh can use it via the TPM PKCS#11 lib. I'm using that daily on multiple machines and it's working great.
I was just telling someone else how great Woodpecker is.
The protocol that Actions runners use to report logs/job statuses back to Gitea is an open protocol that maybe one day woodpecker could use it for enhanced integration with Gitea, so you could use woodpecker but have the experience be next to your code.
Disclaimer: I am listed as a maintainer of Woodpecker. I am a also part of the Gitea TOC, and am employed to work on Gitea
And a lot of power (probably same or more than the device itself). Some space on the board too. While I think it would be nice to include on the board, it is for sure the better option to not include it and let people use an adapter for their use case.
Leveraging XMPP to deliver notifications for Matrix feels like an odd matchup. Or is that just because Synapse + FluffyChat support UnifiedPush and the use of XMPP is purely coincidental/incidental?
(Trying to wrap my head around the architecture too, with the last sentence there. Presumably the service and client need to know how to talk to the UnifiedPush provider?)
It is kinda weird. However, at the end of the day, UnifiedPush is just a protocol that allows $heavyProtocolA to receive notifications through $lightProtocolB.
And XMPP is just $lightProtocolB, there is nothing stopping an XMPP-based UnifiedPush distributor w/o messaging from existing. If you don't use XMPP for messaging, there are many simpler distributors available.
Is it really about light vs. heavy though? I thought it was mostly about multiplexing notifications through a single app (usually through a single connection as well), so only one app has to consume resources constantly, and others might be activated as needed.
It's a little bit of both. You want to only keep one connection open as it minimizes the amount of network activity for e.g. keepalives. You also don't want the app holding that connection open to drain the battery in the process though.
