Welp, there go my Git signatures(karl.kornel.us)
karl.kornel.us
Welp, there go my Git signatures
http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/
48 comments
The DAG-chain argument is kinda valid but misses the core point: I don't validate an entire codebase every time I commit. I just validate the diff. If later on a commit comes into the codebase that has some sort of evil action then it means that a host of possible scenarios can be ruled out (such as someone else easily faking the commit as me).
But if you want to get my key you have to get into my dev machine. There is a class of people that can do that, but it substantially raises the bar. Really what I would like is to make it so my Github account only accepts signed commits, so that it is impossible to impersonate me without my key.
But if you want to get my key you have to get into my dev machine. There is a class of people that can do that, but it substantially raises the bar. Really what I would like is to make it so my Github account only accepts signed commits, so that it is impossible to impersonate me without my key.
> I don't validate an entire codebase every time I commit.
Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.
Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.
> Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed.
And Linus is missing the point entirely.
Yes, signing a commit implicitly signs the repo all the way back to its beginning. But when I'm actually performing the action of signing this commit, I am not actually going back through every commit and verifying them.
The fact that you can use the properties of commit hashes to verify a chain all the way back to the origin of the repo is irrelevant, because that's not what someone actually signing a commit is intending or should be expected to do.
When I'm signing a commit, I'm vouching that I am responsible for applying this set of changes to a given state of a repo. It says nothing about my belief in the validity of changes to the repo made before it.
And Linus is missing the point entirely.
Yes, signing a commit implicitly signs the repo all the way back to its beginning. But when I'm actually performing the action of signing this commit, I am not actually going back through every commit and verifying them.
The fact that you can use the properties of commit hashes to verify a chain all the way back to the origin of the repo is irrelevant, because that's not what someone actually signing a commit is intending or should be expected to do.
When I'm signing a commit, I'm vouching that I am responsible for applying this set of changes to a given state of a repo. It says nothing about my belief in the validity of changes to the repo made before it.
>> For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.
The above example still makes sense, even given your point about the mild absurdity of the idea that the entire repo is implicitly trusted.
The above example still makes sense, even given your point about the mild absurdity of the idea that the entire repo is implicitly trusted.
While this is technically true, what's the point in making the whole thing more complicated?
Say you relax the restrictions such that only the first parent of every commit must be signed. While this might make sense for a small branch edited by one person, what if it was a long-lived branch modified by multiple people?
The only case I can see for such a system is if you're doing a pull-request based workflow where your code review tool (GHE, Bitbucket, whatever) is the only tool capable of updating `master` and produces signed merge commits whenever a branch passes code review. Then you can at least (in theory) attest that all commits to master have been reviewed.
But if not that, and people are signing their commits to master anyway (which you can automate in your `~/.gitconfig`, why allow exemptions to commits on branches?
Say you relax the restrictions such that only the first parent of every commit must be signed. While this might make sense for a small branch edited by one person, what if it was a long-lived branch modified by multiple people?
The only case I can see for such a system is if you're doing a pull-request based workflow where your code review tool (GHE, Bitbucket, whatever) is the only tool capable of updating `master` and produces signed merge commits whenever a branch passes code review. Then you can at least (in theory) attest that all commits to master have been reviewed.
But if not that, and people are signing their commits to master anyway (which you can automate in your `~/.gitconfig`, why allow exemptions to commits on branches?
> When I'm signing a commit, I'm vouching that I am responsible for applying this set of changes to a given state of a repo. It says nothing about my belief in the validity of changes to the repo made before it.
Then you should be signing a diff not a commit. Signing a commit represents something different, because commit references both the current tree (all files) and parent commit you're basically vouching for all history and all files.
For reference, git commit structure [0]:
Then you should be signing a diff not a commit. Signing a commit represents something different, because commit references both the current tree (all files) and parent commit you're basically vouching for all history and all files.
For reference, git commit structure [0]:
$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
author Scott Chacon <[email protected]> 1205815931 -0700
committer Scott Chacon <[email protected]> 1240030591 -0700
changed the version number
That's ridiculous. If I signed a statement saying "The file with this hash is malware: <hash here>" would you say that "you're basically vouching for that file" just because my statement contained the file's hash?
Similarly, if I sign a commit containing `parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7`, that says nothing about whether I consider all previous commits to be valid. It only says that the commit I just signed was created based off of that parent commit, and that in order to see the changes I actually made you'll need to diff against that parent. (Which `git show <my commit id>` will do automatically.)
Similarly, if I sign a commit containing `parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7`, that says nothing about whether I consider all previous commits to be valid. It only says that the commit I just signed was created based off of that parent commit, and that in order to see the changes I actually made you'll need to diff against that parent. (Which `git show <my commit id>` will do automatically.)
I think I used the word vouch incorrectly. When you sign a commit you indicate that your changes can be applied only on that particular parent even if all files or diffs were bit for bit identical. If it didn't work like that someone could take your work and place it in a completely different project and claim it was signed by you.
Note that even with signed commits there are same gaps in the system. For example without signed pushes someone can take your signed commit from branch "test" an push it to "master".
Note that even with signed commits there are same gaps in the system. For example without signed pushes someone can take your signed commit from branch "test" an push it to "master".
Signing a diff by itself is useless, because there's no attestation to what exactly is being diffed.
Just because a signing a commit can be construed as the author attesting to the authenticity of every single bit in the a repo's entire commit history doesn't mean it should, doesn't mean it's what the signing party actually intended, and doesn't mean that such an inference even remotely sane. Such an expectation is utterly absurd on its face for any repo with more than a handful of commits and/or authors.
Further, git does not have a mechanism for signing either diffs or diffs plus the `tree` of the prior commit plus all of the other commit metadata. Even if it did, there's now the problem that by excluding the prior commit, you now have no way of ensuring that signed commits are properly ordered if they happen to share `tree`s (e.g., in the case of a revert). This is a patently terrible property from a cryptographic perspective.
Given the above, there is literally no native way in git to achieve the semantics of signing a singular diff. Combined with the complete absurdity of assuming a signed commit is attesting to tens of thousands of commits or more from dozens of authors or more preceding it, signing commits is the most natural way to express the useful semantic of "I made this change to this tree".
The semantics you suggest are totally unrealistic and virtually useless in practice, so what exactly is the point of your argument?
Just because a signing a commit can be construed as the author attesting to the authenticity of every single bit in the a repo's entire commit history doesn't mean it should, doesn't mean it's what the signing party actually intended, and doesn't mean that such an inference even remotely sane. Such an expectation is utterly absurd on its face for any repo with more than a handful of commits and/or authors.
Further, git does not have a mechanism for signing either diffs or diffs plus the `tree` of the prior commit plus all of the other commit metadata. Even if it did, there's now the problem that by excluding the prior commit, you now have no way of ensuring that signed commits are properly ordered if they happen to share `tree`s (e.g., in the case of a revert). This is a patently terrible property from a cryptographic perspective.
Given the above, there is literally no native way in git to achieve the semantics of signing a singular diff. Combined with the complete absurdity of assuming a signed commit is attesting to tens of thousands of commits or more from dozens of authors or more preceding it, signing commits is the most natural way to express the useful semantic of "I made this change to this tree".
The semantics you suggest are totally unrealistic and virtually useless in practice, so what exactly is the point of your argument?
How do you just a diff in git?
That's workflow similar to what Linux Kernel uses: http://www.vflare.org/2009/09/linux-kernel-workflow-with-git...
In our group's use case, we're not after the "implicitly-signed" property. We are trying to ensure that the person who is listed as doing the commit actually did the commit. We then have a server-side hook script, which ensures each new commit has been signed by a key kept in a local keyring.
Just out of curiosity do you somehow update the local keyring? So that one can update their key information (for example to add revocations and new keys).
There's a single-digit number of people who can update the local keyring. Which works right now, given that the number of people who push to the repos concerned is in the double-digit range.
Our PGP keys don't really change that often.
Our PGP keys don't really change that often.
> One interesting voice in signing all commits by Linus:
>> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.
I've never bought that argument.[0] You should use whatever method actually addresses your threat model. If you're going to sign every commit (I do), then commit (no pun intended) to doing so properly. I use `git add -p` for every commit and review my changes, and enter my smartcard PIN for every single commit. I use it to assert my identity on those commits. If you automate signing past commits, then you open yourself up to attack. Saying "this idea is stupid because everyone is going to do it wrong" is not the basis of a strong argument.
The other part of his argument is that the DAG itself allows you to just sign a single commit to verify the entire history. Firstly: that's different than signing each commit, which asserts identity of the author. Secondly, which has always been my argument, is that it rests on the security of SHA-1, which has been under question for quite a while, and has since been demonstrably broken. Are second preimage attacks unlikely with SHA-1? At least today, yes. Consider your threat model. Linus didn't even do that. He said long ago that SHA-1 was intended for integrity, not security, so retrofitting it in an argument is also not useful.
[0]: https://mikegerwitz.com/papers/git-horror-story#merge-3
([0] from 2012 doesn't address the issue in this thread---expired or revoked keys.)
>> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.
I've never bought that argument.[0] You should use whatever method actually addresses your threat model. If you're going to sign every commit (I do), then commit (no pun intended) to doing so properly. I use `git add -p` for every commit and review my changes, and enter my smartcard PIN for every single commit. I use it to assert my identity on those commits. If you automate signing past commits, then you open yourself up to attack. Saying "this idea is stupid because everyone is going to do it wrong" is not the basis of a strong argument.
The other part of his argument is that the DAG itself allows you to just sign a single commit to verify the entire history. Firstly: that's different than signing each commit, which asserts identity of the author. Secondly, which has always been my argument, is that it rests on the security of SHA-1, which has been under question for quite a while, and has since been demonstrably broken. Are second preimage attacks unlikely with SHA-1? At least today, yes. Consider your threat model. Linus didn't even do that. He said long ago that SHA-1 was intended for integrity, not security, so retrofitting it in an argument is also not useful.
[0]: https://mikegerwitz.com/papers/git-horror-story#merge-3
([0] from 2012 doesn't address the issue in this thread---expired or revoked keys.)
But isn't signing commits basically relying on SHA-1 values of tree and parent (this is what is signed ultimately [0])? That'd be the weakest link of the system.
[0]: https://news.ycombinator.com/item?id=10353456
[0]: https://news.ycombinator.com/item?id=10353456
> I don’t have a record of every signature I made
Use opentimestamps git wrapper. Each commit is signed and timestamped. When you revoke your key, the original signed commit is still timestamped, presumably before your revocation date.
https://github.com/opentimestamps/opentimestamps-client
https://opentimestamps.org/
Use opentimestamps git wrapper. Each commit is signed and timestamped. When you revoke your key, the original signed commit is still timestamped, presumably before your revocation date.
https://github.com/opentimestamps/opentimestamps-client
https://opentimestamps.org/
Dude. That looks awesome. It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), but that would probably need messing with GPG in some way.
(What I mean is, a GPG signature includes a space for "sub-packets" of information, stored in in "length-type-value" form. See RFC 4480 Section 5.2.3 for the overall signature packet format. The OpenTimestamp data could be embedded as a sub-packet, causing its content to also be signed.)
It looks like this site was posted 12 days ago by handpickednames in https://news.ycombinator.com/item?id=15456521, but it didn't get must attention. I think people should check it out!
(Disclaimer: I don't have any position in Bitcoin or blockchain right now.)
(What I mean is, a GPG signature includes a space for "sub-packets" of information, stored in in "length-type-value" form. See RFC 4480 Section 5.2.3 for the overall signature packet format. The OpenTimestamp data could be embedded as a sub-packet, causing its content to also be signed.)
It looks like this site was posted 12 days ago by handpickednames in https://news.ycombinator.com/item?id=15456521, but it didn't get must attention. I think people should check it out!
(Disclaimer: I don't have any position in Bitcoin or blockchain right now.)
> It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet),
Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`:
[0]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction).
For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency
Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`:
# off=0 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 5D3EB2F8800430EB
version 4, created 1399174181, md5len 0, sigclass 0x00
digest algo 2, begin of digest 65 b4
hashed subpkt 2 len 4 (sig created 2014-05-04)
subpkt 16 len 8 (issuer key ID 5D3EB2F8800430EB)
data: [2047 bits]
[0]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction).
For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency
Sorry, I should have been clearer. Here's what I meant to say:
>It kindof annoys me that the _OpenTimestamp_ wasn't somehow worked into the signature itself (like as a sub-packet),
>It kindof annoys me that the _OpenTimestamp_ wasn't somehow worked into the signature itself (like as a sub-packet),
> For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency
To be clear, OpenTimestamps doesn't require you to spend money to create a timestamp, as it has a set of public calender servers that pool timestamp requests, allowing all OTS users to share the same BTC transaction (which itself is paid out of donations).
To be clear, OpenTimestamps doesn't require you to spend money to create a timestamp, as it has a set of public calender servers that pool timestamp requests, allowing all OTS users to share the same BTC transaction (which itself is paid out of donations).
[deleted]
> but that would probably need messing with GPG in some way.
That's exactly why I didn't do that: the OpenPGP standard is extremely complex, good libraries to do that kind of thing just don't exist, and it was unclear what compatibility issues I'd be adding if I did that.
That's exactly why I didn't do that: the OpenPGP standard is extremely complex, good libraries to do that kind of thing just don't exist, and it was unclear what compatibility issues I'd be adding if I did that.
I also have a blog post describing the Git timestamping use-case: https://petertodd.org/2016/opentimestamps-git-integration
Maybe Git could leverage git-notes as a mechanism for allowing re-signing commits without changing the hashes.
Oh, interesting! There's a new thing about Git that I learned today…
With notes, I think the merge strategy may need to be changed, in case multiple people want to re-sign the same commit, but that shouldn't be too bad. The only thing left is to find a way to leverage the functionality, but having the foundation there should make it much easier!
With notes, I think the merge strategy may need to be changed, in case multiple people want to re-sign the same commit, but that shouldn't be too bad. The only thing left is to find a way to leverage the functionality, but having the foundation there should make it much easier!
That exactly how one can put multiple signatures on a commit.
Could you plz provide an example ?
Check out Notes Towards Detached Signatures in Git [0].
[0]: https://grimoire.ca/git/detached-sigs
[0]: https://grimoire.ca/git/detached-sigs
That's interesting! You should post that to HN directly, since it hasn't been posted before.
Git's underlying data model is simple yet extremely flexible (see e.g. [0]), well just like OpenPGP I guess.
As for the article you're welcome to post it yourself :)
[0]: https://github.com/google/git-appraise
As for the article you're welcome to post it yourself :)
[0]: https://github.com/google/git-appraise
[deleted]
> I don’t have a record of every signature I made.
Somebody please make a search engine for public OpenPGP signatures.
Somebody please make a search engine for public OpenPGP signatures.
> every commit after this one will make it harder for
someone to go back and change the note
Maybe you should also add some proof of work and make your commit hashes start with certain patterns?
Maybe you should also add some proof of work and make your commit hashes start with certain patterns?
Why would you have a shared SSH authentication key and PGP signing key? That just seems like a really silly idea, and leads to having to deal with situations like this.
Logging into a system remotely is a much different activity than signing a file.
Logging into a system remotely is a much different activity than signing a file.
This is the awesome part, they're actually separate keys, with separate policies!
(Or, well, separate sub-keys.)
With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.
Unfortunately, it doesn't look like you can see it on a public key server, but you can see this yourself if you have GPG, using these two commands:
gpg --keyserver pgp.mit.edu --recv-keys e5e5afc8 gpg -k e5e5afc8
(You might not need the `--keyserver pgp.mit.edu` part, if you have a keyserver specified already in your ~/.gnupg/gpg.conf file.)
(Also, I'm using GPG version 2.2.0. Older versions might not show the same content. For example, GPG 1.4.16 does not.)
The first line of output from the second command should be this:
Later on, you have entries like this:
The signing sub-key is what was generated on my Yubikey, and is used for signing stuff like email and Git commits. The authentication sub-key was _also_ generated on my Yubikey, and is what gets transformed into an SSH key.
So, each sub-key is a key in its own right. The only common things between them are that they are bound into the same GPG public key, and they are contained on the same physical device.
One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.
So yes, different activities, each with a key explicitly marked for that activity, with different policies as to how I can access it.
(Or, well, separate sub-keys.)
With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.
Unfortunately, it doesn't look like you can see it on a public key server, but you can see this yourself if you have GPG, using these two commands:
gpg --keyserver pgp.mit.edu --recv-keys e5e5afc8 gpg -k e5e5afc8
(You might not need the `--keyserver pgp.mit.edu` part, if you have a keyserver specified already in your ~/.gnupg/gpg.conf file.)
(Also, I'm using GPG version 2.2.0. Older versions might not show the same content. For example, GPG 1.4.16 does not.)
The first line of output from the second command should be this:
pub rsa4096 2015-12-13 [SC] [expires: 2025-12-10]
Later on, you have entries like this:
sub rsa4096 2015-12-13 [E] [expires: 2025-12-10]
sub rsa4096 2017-10-21 [A] [expires: 2019-04-14]
sub rsa4096 2017-10-21 [S] [expires: 2019-04-14]
The signing sub-key is what was generated on my Yubikey, and is used for signing stuff like email and Git commits. The authentication sub-key was _also_ generated on my Yubikey, and is what gets transformed into an SSH key.
So, each sub-key is a key in its own right. The only common things between them are that they are bound into the same GPG public key, and they are contained on the same physical device.
One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.
So yes, different activities, each with a key explicitly marked for that activity, with different policies as to how I can access it.
> With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.
Well it's only by-convention [0]:
> By convention, the top-level key provides signature services, and the subkeys provide encryption services.
[0]: https://tools.ietf.org/html/rfc4880#section-5.5.1.2
Personally I left the main key with Certify only (disabled Sign when creating the key with expert mode) and generated signing keys as subkeys.
> One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.
A middle ground for encryption and authentication keys is Yubico's touch-to-use [1], you enter your PIN once and then have to touch the token to use the key.
[1]: https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_...
Well it's only by-convention [0]:
> By convention, the top-level key provides signature services, and the subkeys provide encryption services.
[0]: https://tools.ietf.org/html/rfc4880#section-5.5.1.2
Personally I left the main key with Certify only (disabled Sign when creating the key with expert mode) and generated signing keys as subkeys.
> One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.
A middle ground for encryption and authentication keys is Yubico's touch-to-use [1], you enter your PIN once and then have to touch the token to use the key.
[1]: https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_...
Assuming your encryption subkey was also generated on the YubiKey, why did you not replace it as well?
My encryption subkey was explicitly _not_ generated inside the Yubikey. That was an intentional choice; I chose to sacrifice some security by generating the key in software and transferring it to the Yubikey, in exchange for the convenience of having the ability to do so again in the future. I made that choice because the encryption subkey is the one kind of subkey where I do not have full control over its use.
What I mean is (for people still getting into this PGP stuff), with the signing and authentication subkeys, I'm the one who is performing those actions (ignoring things like compromised keys). For encryption, the sender is the one who chooses which of the encryption subkeys to use, and there is no way for me to be sure that their copy of my public key is up-to-date.
(Totally off-the-rails side note: For anyone who works with Kerberos, and aliases/CNAMEs, you also have to deal with this problem, because it's the client who chooses exactly which service principal to request a ticket for.)
I know that my current encryption subkey isn't going to last forever, but I wanted to be able to use it on multiple "cards" (or in this case, a Yubikey).
What I mean is (for people still getting into this PGP stuff), with the signing and authentication subkeys, I'm the one who is performing those actions (ignoring things like compromised keys). For encryption, the sender is the one who chooses which of the encryption subkeys to use, and there is no way for me to be sure that their copy of my public key is up-to-date.
(Totally off-the-rails side note: For anyone who works with Kerberos, and aliases/CNAMEs, you also have to deal with this problem, because it's the client who chooses exactly which service principal to request a ticket for.)
I know that my current encryption subkey isn't going to last forever, but I wanted to be able to use it on multiple "cards" (or in this case, a Yubikey).
> My encryption subkey was explicitly _not_ generated inside the Yubikey.
I figured that was the reason.
I use an offline master key and have separate [S,E,A] subkeys on my YubiKeys as well, although I generated them on a machine that is fairly well hardened and offline anyways -- mostly because I didn't want to risk losing them but also because I have multiple YubiKeys that I wanted to use them on.
I figured that was the reason.
I use an offline master key and have separate [S,E,A] subkeys on my YubiKeys as well, although I generated them on a machine that is fairly well hardened and offline anyways -- mostly because I didn't want to risk losing them but also because I have multiple YubiKeys that I wanted to use them on.
For reference for other people this is called Key Escrow [0].
[0]: https://en.wikipedia.org/wiki/Key_escrow
[0]: https://en.wikipedia.org/wiki/Key_escrow
I don't think it is exactly key escrow, because there is no third-party involved. I generated my own keys for my own use, and nobody has access to them (that I know of).
I know this might just be a semantic argument, but the Wikipedia article linked is a good example of how controversial proper key escrow (involving a third party) is.
If I'd refer people to a Wikipedia article, the article on Key Management (https://en.wikipedia.org/wiki/Key_management) might be a better one, as it is more general, and my blog post touches on many key management topics.
I know this might just be a semantic argument, but the Wikipedia article linked is a good example of how controversial proper key escrow (involving a third party) is.
If I'd refer people to a Wikipedia article, the article on Key Management (https://en.wikipedia.org/wiki/Key_management) might be a better one, as it is more general, and my blog post touches on many key management topics.
Okay, I hadn't followed that in your post. Thank you for clarifying.
Not really. In both cases you are merely attesting as to who you are.
If you want to get pedantic, yes. However, the intent of what you are doing is, in my mind, much different.
Logging into a system expresses the intent to run something there - you want to perform some actions as a result of authenticating - it's an active process.
Signing a document is about authenticating the document - it's something passive.
Logging into a system expresses the intent to run something there - you want to perform some actions as a result of authenticating - it's an active process.
Signing a document is about authenticating the document - it's something passive.
For me it's not a problem that old commits are signed with revoked keys, there are several ways one can get old broken signatures (e.g. key rotation) and by design they should not be trusted.
One interesting voice in signing all commits by Linus:
> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.
Source: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
Also, depending one one's threat model signing all commits can still be not sufficient: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...