signed git tags #108

Closed
opened 2013-04-05 00:26:08 +02:00 by adrelanos · 15 comments
adrelanos commented 2013-04-05 00:26:08 +02:00 (Migrated from github.com)

It would be nice if you could provide signed git tags for new releases.

It would be nice if you could provide signed git tags for new releases.
Atheros1 commented 2013-04-06 00:07:22 +02:00 (Migrated from github.com)

This would be so that I am authenticating the code at points in time, yes?

This would be so that I am authenticating the code at points in time, yes?
adrelanos commented 2013-04-06 00:16:50 +02:00 (Migrated from github.com)

Yes.

Yes.
Atheros1 commented 2013-04-06 17:27:07 +02:00 (Migrated from github.com)

I feel like if someone were able to push code using my account, there is a good chance that it is because they are already in my system.

I feel like if someone were able to push code using my account, there is a good chance that it is because they are already in my system.
adrelanos commented 2013-04-06 17:42:37 +02:00 (Migrated from github.com)

It's also useful in case github gets hacked again in case SSL CA's get hacked again.

It's also useful in case github [gets hacked](http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted) again in case [SSL CA's](https://en.wikipedia.org/wiki/DigiNotar) get [hacked](http://www.scmagazine.com/two-more-comodo-resellers-owned-in-ssl-hack/article/199620/) again.
ISibboI commented 2013-04-06 17:57:15 +02:00 (Migrated from github.com)

Well, I guess right now that's a nice to have, but from v1.0 onwards you should do that. And keep the key on an USB stick locked in a safe or something like that.

Well, I guess right now that's a nice to have, but from v1.0 onwards you should do that. And keep the key on an USB stick locked in a safe or something like that.
adrelanos commented 2013-04-06 18:07:05 +02:00 (Migrated from github.com)

To defeat system compromise, it's also possible to have an offline (air gaped) gpg key. (some instructions)

To defeat system compromise, it's also possible to have an offline (air gaped) gpg key. ([some instructions](http://wiki.debian.org/subkeys))
justusranvier commented 2013-06-03 21:51:21 +02:00 (Migrated from github.com)

I don't even see any release tags in the repository at all, signed or otherwise. It would be nice to at least include those even if they aren't signed.

I don't even see any release tags in the repository at all, signed or otherwise. It would be nice to at least include those even if they aren't signed.
grant-olson commented 2013-08-07 18:03:55 +02:00 (Migrated from github.com)

Yeah there should be release tags. Right now you can't, for example, tell what API calls are part of the stable release. And once you're generating the tags, you might as well sign them.

Yeah there should be release tags. Right now you can't, for example, tell what API calls are part of the stable release. And once you're generating the tags, you might as well sign them.
fiatflux commented 2013-08-08 18:04:15 +02:00 (Migrated from github.com)

Smartcards are the way to go. But even without one, I strongly support GPG-signed release tags.

Smartcards are the way to go. But even without one, I strongly support GPG-signed release tags.
domob1812 commented 2013-08-09 07:41:43 +02:00 (Migrated from github.com)

I'd also love to see tags to document the releases in Git, and signed if possible (even if you think it's not that much additional safety, it can't hurt to have an extra layer).

I'd also love to see tags to document the releases in Git, and signed if possible (even if you think it's not that much additional safety, it can't hurt to have an extra layer).
Klexx commented 2014-12-16 20:47:13 +01:00 (Migrated from github.com)

+1 as this is no big deal: GPG sign commit

+1 as this is no big deal: [GPG sign commit](https://ariejan.net/2014/06/04/gpg-sign-your-git-commits/)
adrelanos commented 2014-12-21 00:58:38 +01:00 (Migrated from github.com)

Signing/verifying git commits is also useful for security. Especially if
it's a signed commit that gets a signed git tag. See also:
http://mikegerwitz.com/papers/git-horror-story

Signing git commits can also be simplified, done transparently, in
recent git versions. Using commit.gpgsign + no-ff merge option + signing
key id in settings.

Signing/verifying git commits is also useful for security. Especially if it's a signed commit that gets a signed git tag. See also: http://mikegerwitz.com/papers/git-horror-story Signing git commits can also be simplified, done transparently, in recent git versions. Using commit.gpgsign + no-ff merge option + signing key id in settings.
absorber commented 2014-12-21 10:58:55 +01:00 (Migrated from github.com)

👍

For when GitHub and / or certs get compromised.

:+1: For when GitHub and / or certs get compromised.
ghost commented 2015-06-24 18:36:43 +02:00 (Migrated from github.com)

+1 This is pretty straightforward to do.

+1 This is pretty straightforward to do.
PeterSurda commented 2015-10-29 15:48:07 +01:00 (Migrated from github.com)

I have been signing pgp commits in my fork for a while. I screwed up signing the tag, but I'll know how to do it next time. I'm using key 53FBF089. I'll have a new key next week, I'll make the appropriate announcements.

I kindly request people who make pull requests to also sign their commits.

I have been signing pgp commits [in my fork](https://github.com/mailchuck/PyBitmessage/releases/tag/v0.5.0) for a while. I screwed up signing the tag, but I'll know how to do it next time. I'm using key 53FBF089. I'll have a new key next week, I'll make the appropriate announcements. I kindly request people who make pull requests to also sign their commits.
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-13#108
No description provided.