A similar idea was described in 2015: https://grimoire.ca/git/detached-sigs
Git-signatures – Multiple PGP signatures for your commits
11–15 of 15 posts
Re: Git-signatures – Multiple PGP signatures for your commits
#12Is there anything out there that doesn't need GPG? Having a working GPG install is a huge lift for developers.
I take this to mean: apart from the barnacles on GPG, could there be a system which does what GPG does for software development (signing), without the non-functioning web-of-trust of GPG, or the hierarchical system of x509 signing? Something that deals with lost keys, compromised keys/accounts, loss of DNS control, MitMing, MitBing, etc? I think it is probably in the class of problems where there are no great foolpro…
keybase.io is a really solid approach for trusting that a given key is owned by a certain person. Basically, it's a centralized registry to list your keys, and you can publish proof of key-ownership on any website/social media that you own. So anyone can look up my public key from my twitter or github, and know that they're both me.
Some people object to it because it lets you store your keys with them (encrypted with a passphrase), but that's always been optional.
Re: Git-signatures – Multiple PGP signatures for your commits
#13Earlier quoted context omitted.
I take this to mean: apart from the barnacles on GPG, could there be a system which does what GPG does for software development (signing), without the non-functioning web-of-trust of GPG, or the hierarchical system of x509 signing? Something that deals with lost keys, compromised keys/accounts, loss of DNS control, MitMing, MitBing, etc? I think it is probably in the class of problems where there are no great foolpro…
keybase.io is a really solid approach for trusting that a given key is owned by a certain person. Basically, it's a centralized registry to list your keys, and you can publish proof of key-ownership on any website/social media that you own. So anyone can look up my public key from my twitter or github, and know that they're both me. Some people object to it because it lets you store your keys with them (encrypted wit…
Extra requirements:
- Not trusting one company/hosting provider (like keybase/AWS).
- Works for periodically or totally offline signing and verification.
- Not be an ephemeral record (like a tweet) or undated. - Not require memorisation of very long passphrases.
- Not be subject to mass compromise (i.e. like a bug in a Bitcoin wallet code on android).
Re: Git-signatures – Multiple PGP signatures for your commits
#14Earlier quoted context omitted.
I take this to mean: apart from the barnacles on GPG, could there be a system which does what GPG does for software development (signing), without the non-functioning web-of-trust of GPG, or the hierarchical system of x509 signing? Something that deals with lost keys, compromised keys/accounts, loss of DNS control, MitMing, MitBing, etc? I think it is probably in the class of problems where there are no great foolpro…
> I think it is probably in the class of problems where there are no great foolproof solutions. However, I can imagine that techniques like certificate transparency (all signed x509 certificates pushed to a shared log) would be quite useful. Securing DNS: " https://news.ycombinator.com/item?id=19181362" > Certs on the Blockchain: "Can we merge Certificate Transparency with blockchain?" https://news.ycombinator.com/it…
(Your first link is broken.)
My main problem with blockchain is the excessive energy consumption of PoW. I know there are PoS efforts, but they seem problematical.
I like the recent CertLedger paper: https://eprint.iacr.org/2018/1071.pdf
Re: Git-signatures – Multiple PGP signatures for your commits
#15Earlier quoted context omitted.
> I think it is probably in the class of problems where there are no great foolproof solutions. However, I can imagine that techniques like certificate transparency (all signed x509 certificates pushed to a shared log) would be quite useful. Securing DNS: " https://news.ycombinator.com/item?id=19181362" > Certs on the Blockchain: "Can we merge Certificate Transparency with blockchain?" https://news.ycombinator.com/it…
(Your first link is broken.) My main problem with blockchain is the excessive energy consumption of PoW. I know there are PoS efforts, but they seem problematical. I like the recent CertLedger paper: https://eprint.iacr.org/2018/1071.pdf
My mistake. How ironic. Everything depends upon the red wheelbarrow. Here's that link without the trailing ":
https://news.ycombinator.com/item?id=19181362
> My main problem with blockchain is the excessive energy consumption of PoW. I know there are PoS efforts, but they seem problematical.
One report said that 78% of Bitcoin energy usage is from renewable sources (many of which would otherwise be curtailed and otherwise unfunded due to flat-to-falling demand for electricity). But PoW really is expensive and hopefully the market will choose less energy-inefficient solutions from the existing and future blockchain solutions while keeping equal or better security assurances.
>> Proof of Work (Bitcoin, ...), Proof of Stake (Ethereum Casper), Proof of Space, Proof of Research (GridCoin, CureCoin,)
The spec should be: DDOS resiliant (without a SPOF), no one entity with control over API and/or database credentials and database backups and the clock, and immutable.
Immutability really cannot be ensured with hashed records that incorporate the previous record's hash as a salt in a blocking centralized database because someone ultimately has root and the clock and all the backups and code vulnerable to e.g. [No]SQL injection; though distributed 'replication' and detection of record modification could be implemented. git push -f may be detected if it's on an already-replicated branch; but git depends upon local timestamps. google/trillian does Merkle trees in a centralized database (for Certificate Transparency).
In quickly reading the git-signatures shell script sources, I wasn't certain whether the git-notes branch with the .gitsigners that are fetched from all n keyservers (with DNS) is also signed?
I also like the "Table 1: Security comparison of Log Based Approaches to Certificate Management" in the CertLedger paper. Others are far more qualified to compare implementations.