3 ms·

Why is this a problem, the key was valid however at the time the commit was made? > https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/ Huh? Rep

Why is this a problem, the key was valid however at the time the commit was made? > https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/ Huh? Replace one convoluted process for another convoluted and less capable one? Seems like not invented here syndrome. Not surprised it's not used. If you're using email for critical, sensitive work, spend the 15 minutes to learn how PGP works and another to set it up. You can even sign your git commits and tags with them! Also, get some yubikeys, they work well with pgp.

rakoo 6y ago
I think you need 15 minutes to understand what the problem is about. An email-based workflow like the one the linux tree uses is based on patches, not commits. You may want to sign commits but it will be useless because commits aren't exchanged. So the proposed process doesn't "replace" anything: there's no signing in the first place. You can't sign patches directly because then they wouldn't be usable by the git tools like git-am. So you need a meta data-structure that contains all patches and relevant information kinda like a pseudo-commit: the author, message and patch itself. Then that meta data-structure can be pgp-encrypted and sent by email, as described by your link and as you implied was not done > Why is this a problem, the key was valid however at the time the commit was made? You want to check the validity of a commit at the moment you use it, not the moment the commit was made: imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired. What's the use of that signature ? Can a third-party cherry-pick that commit and trusting that "the key was valid at the time the commit was made" ? You can sign that you did something at some point but you can't sign that you never did something, or that you never used a given key. > spend the 15 minutes to learn how PGP works and another to set it up You can't seriously believe that it takes 15 minutes to understand how PGP works and 15 minutes to set up a functional environment and expect it to follow the best standards. Even reading the kernel's documentation on how to use pgp (https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-guide.html# https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-...) takes more than 15 minutes. > Also, get some yubikeys, they work well with pgp. I don't understand what's the link with the rest of the discussion
- waynesonfire 6y ago
  > You want to check the validity of a commit at the moment you use it, not the moment the commit was made If you received the repo before the key expired, you can still trust the signature even if the key has since expired, as the key was valid at that time the repo was signed. > imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired Yes, you cant trust a key after after it's expiration. See bottom of https://www.kernel.org/signature.html https://www.kernel.org/signature.html for how the kernel.org folks handled this in 2011. Once they re-signed the release, it's safe to trust the compromised key within that release. > I don't understand what's the link with the rest of the discussion We're discussing complexity of pgp adoption, security cards simplify the usage of pgp, thought it was relevant.

rakoo 6y ago

I think you need 15 minutes to understand what the problem is about. An email-based workflow like the one the linux tree uses is based on patches, not commits. You may want to sign commits but it will be useless because commits aren't exchanged. So the proposed process doesn't "replace" anything: there's no signing in the first place. You can't sign patches directly because then they wouldn't be usable by the git tools like git-am. So you need a meta data-structure that contains all patches and relevant information kinda like a pseudo-commit: the author, message and patch itself. Then that meta data-structure can be pgp-encrypted and sent by email, as described by your link and as you implied was not done > Why is this a problem, the key was valid however at the time the commit was made? You want to check the validity of a commit at the moment you use it, not the moment the commit was made: imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired. What's the use of that signature ? Can a third-party cherry-pick that commit and trusting that "the key was valid at the time the commit was made" ? You can sign that you did something at some point but you can't sign that you never did something, or that you never used a given key. > spend the 15 minutes to learn how PGP works and another to set it up You can't seriously believe that it takes 15 minutes to understand how PGP works and 15 minutes to set up a functional environment and expect it to follow the best standards. Even reading the kernel's documentation on how to use pgp (https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-guide.html# https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-...) takes more than 15 minutes. > Also, get some yubikeys, they work well with pgp. I don't understand what's the link with the rest of the discussion

waynesonfire 6y ago
> You want to check the validity of a commit at the moment you use it, not the moment the commit was made If you received the repo before the key expired, you can still trust the signature even if the key has since expired, as the key was valid at that time the repo was signed. > imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired Yes, you cant trust a key after after it's expiration. See bottom of https://www.kernel.org/signature.html https://www.kernel.org/signature.html for how the kernel.org folks handled this in 2011. Once they re-signed the release, it's safe to trust the compromised key within that release. > I don't understand what's the link with the rest of the discussion We're discussing complexity of pgp adoption, security cards simplify the usage of pgp, thought it was relevant.