search

debops / ansible-ifupdown

Manage network interface configuration in /etc/network/interfaces
GNU General Public License v3.0
25 stars 14 forks source link

Template indentation. #48

Closed ypid closed 8 years ago

ypid commented 8 years ago

Mostly indention. Three instances of default filter improvements. I thought there was a better word diff on GitHub. git diff --color-words can show the relevant diff.

drybjed commented 8 years ago

@ypid Are you signing git commits manually?

ypid commented 8 years ago

@drybjed Why manually :wink: ?

Let me elaborate a bit more on this so that I can reference it later because I am quite happy with my code signing policy.

I use a set of three PGP keys: https://wiki.debian.org/ypid?action=recall&rev=1

I am quite aware that there are some opinions about how useful this is (see What are the advantages and disadvantages of cryptographically signing commits and tags in Git?). I think with this set of multiple keys with different trust levels I can get the best of both worlds (integrity of each commit and a more trusted release compared to only signing releases).

This has the nice side effect that if I touch a repository (make a signed commit) that additionally locks the history of the project as well and makes it more difficult to corrupt git history later. (In the hope that SHA1 can still provide that level of security and that git maintainers will switch to something more appropriate soon).

GitHub has recently added those nice badges for signed commits which grandly increases the visibility/importance which I think is awesome and encourages me in what I have been doing for some time now.

drybjed commented 8 years ago

I'm aware of that automating commit signing controversy, that's why I asked. And I think that your commits are the first ones I've noticed being verified.

It seems that with this recent GitHub move to emphasize signed commits they might become more... valuable? Not sure how to put that. So far I have only signed tags, I'm not sure if signing commits would be better seen by the community, although after thinking about it for a bit it wouldn't be that hard for me to start doing. I'm keeping my GPG key on a Yubikey, so I wouldn't automate the process. I'm usually doing many commits in short bursts, so signing each of them shouldn't be a problem.

ypid commented 8 years ago

@drybjed controversy is the right word. I think signing every commit only makes sense under certain conditions. The most important one being not to use once primary PGP key as, like in your case, that would make your signature worth less as you take special effort to keep your private key protected. So for this to make sense generating a PGP key for automatic signing and then only signing that key with your master key I think is the preferred way. That also allows for people to easily see which if you intentionally released something or not.

And I think that your commits are the first ones I've noticed being verified.

I have seen a few other people doing this. Always depends on in which project you look into and how security aware/paranoid they are.

drybjed commented 8 years ago

@ypid Ah, obviously my master GPG key is offline, and I have only subkeys on a Yubikey which I use daily, so I suppose that should be sufficient? Do you think that if I started signing DebOps commits, you would feel more at ease and more confident using that code?

ypid commented 8 years ago

Obviously my master GPG key is offline, and I have only subkeys on a Yubikey which I use daily

And that is how it is done :+1: Great job :+1:

I still think that it would make sense to introduce a second PGP key only used for commit signing. This way, you could lower the security measure for this key a bit and rotate the key more often. And then only sign release tags with the sig subkey of your master key.

The Qubes OS project goes similar ways using multiple PGP keys: https://github.com/QubesOS

Would feel more at ease and more confident using that code?

Yes, sure! :wink:

drybjed commented 8 years ago

@ypid OK then, I've added my GPG key on GitHub and I'll start signing commits which should be verified. I don't plan to deal with custom signing subkey at the moment, let's see how much more work it will take (I don't think it will be that much). I also plan to sign merge requests, which AFAIK will need for me to get the patches to my workstation and sign manually - is that supported by GitHub interface as well?

Another question is providing a verification and trust path for my GPG key. I imagine that a key signing party would be in order. Some other way to do this would probably be finding a friendly neighbourhood Debian Developer to sign my GPG key with. There's also my profile on keybase.io so that can be used to authenticate my GitHub account against my GPG key.

ypid commented 8 years ago

I also plan to sign merge requests, which AFAIK will need for me to get the patches to my workstation and sign manually - is that supported by GitHub interface as well?

I guess we will also need to think about that. I agree that also signing merge request is a good thing. I would completely loss my trust in GitHub if they offered this feature on the website as well because that would require you to upload you sig public key or maybe use a browser plugin or something. I already sign merge commits most of the time for example for debops.cryptsetup so that should be ok.

Another question is providing a verification and trust path for my GPG key.

Right. That is a good idea. I actually did get my PGP key signed by Jan Dittberner. But providing many different sources to verify your fingerprint also helps I think.

drybjed commented 8 years ago

@ypid OK, here we go, first verified commit and merge. merging manually could be scripted a bit. Perhaps I should look into git-flow to make that easier, have you used it?

ypid commented 8 years ago

Nice :wink: I looked into the git-flow model once but have not really adopted to it. About the tools you linked, not yet.