tag:blogger.com,1999:blog-632023420616344756.post7794421940601879369..comments2024-02-03T12:35:11.129-08:00Comments on Git Blame: Using signed tag in pull requests_http://www.blogger.com/profile/04508668132209394366noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-632023420616344756.post-8660023637167127012012-01-25T09:30:53.811-08:002012-01-25T09:30:53.811-08:00I gave this a try yesterday. One thing I did wrong...I gave this a try yesterday. One thing I did wrong was to cut & paste the repository address I used to push the tag into the "git request-pull" command. This meant that I had to hand edit the generated message to change the gitolite@ra.kernel.org URL to be a git://git.kernel.org one.<br /><br />It might be clearer if you changed the footnote 2, which currently says "the URL of the repository, to which the contributor has pushed" to something like "the public URL of the repository from which the pull will be performed". And perhaps use a "git://example.com" style URL rather than the ssh one.Tony Luckhttps://www.blogger.com/profile/00493946029962526778noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-26570232578485756572012-01-21T12:47:32.777-08:002012-01-21T12:47:32.777-08:00"Eric, you can write your own "git mypul..."Eric, you can write your own "git mypull" convenience wrapper if your project requires such a workflow."<br /><br />What argues against making signature-checking-on-pull a default?Frank Ch. Eiglerhttps://www.blogger.com/profile/06535966377820034604noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-10496310073793723022012-01-19T05:55:05.497-08:002012-01-19T05:55:05.497-08:00I afraid this is a corporate mindset: do without t...I afraid this is a corporate mindset: do without thinking. You generally don't chose to use their products (they suspect you wouldn't if you had the choice).<br /><br />It is wise to plan for this.Alex Riesenhttps://www.blogger.com/profile/17675906805337863487noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-48335727413823658262012-01-18T19:03:38.566-08:002012-01-18T19:03:38.566-08:00Eric, you can write your own "git mypull"...Eric, you can write your own "git mypull" convenience wrapper if your project requires such a workflow. After all, that is why we added "git show --show-signature" so that such a custom verification wrapper can be easily written (and the verification does not have to be only about GPG signatures).<br /><br />Also the development is about people, not mechanical "is this signed?" bit. If you are pulling from a trustworthy site, you do not have to insist on merging signed tags only. The world is not that black and white.<br /><br />Alex, I personally think that people who type without thinking deserve <i>it</i>, whatever it is that you are worried about. This comment applies to Eric's comment as well. I personally wouldn't want to use any product produced by a project that is run by a maintainer who runs "make" after pulling <i>without</i> actually looking at the changes s/he pulled, regardless of the tip s/he pulled is signed or not._https://www.blogger.com/profile/04508668132209394366noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-90791677483496680262012-01-18T16:10:28.150-08:002012-01-18T16:10:28.150-08:00Is there a way to configure git to ensure you only...Is there a way to configure git to ensure you only ever pull signed tags? With something like 'git pull --accept-no-signature' when you want to make an exception?<br /><br />Otherwise, if I understand correctly the current workflow, it looks like a third party can forge a pull request email that makes it look like the tag will be signed, the maintainer does a 'git pull', but if he doesn't pay attention he may in fact be pulling a non-signed history.<br /><br />To be clear, I understand that the merge commit message shows whether the tag was signed or not, and the maintainer can easily manually check with 'git log --show-signature'.<br /><br />What I'm concerned about is something like:<br /><br />- receives forged email<br />- git pull ...<br />- # Looks good, saves message, will amend later after I try it.<br />- make # owned!<br />- Oh shit, was it actually signed? Did I remember to look for the gpg output?<br />- git log --show-signature # too late...<br /><br />Just like you can install a non-signed RPM with yum, but by default it will refuse. You need an explicit option '--nogpgcheck' to make it happen.<br /><br />Thanks.Eric Rannaudhttps://www.blogger.com/profile/05581908998542223500noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-54882640306561524132012-01-18T06:18:07.382-08:002012-01-18T06:18:07.382-08:00Is it not a little bit dangerous to use "+&qu...Is it not a little bit dangerous to use "+" in tag push command?<br />People tend to pay little attention to a state of affairs when they are in hurry, and they tend to usually be in it.Alex Riesenhttps://www.blogger.com/profile/17675906805337863487noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-48209437226925145572012-01-17T18:39:15.300-08:002012-01-17T18:39:15.300-08:00If you insist, I'd prefer to teach the audienc...If you insist, I'd prefer to teach the audience to stick to the general ordering of the command line options, so that should be spelled<br /><br />git push --delete $remote $tag<br /><br />or something.<br /><br />In this particular workflow, however, I am envisioning that most people will keep reusing the same tag for subsequent pull requests (and that is the point of footnote #2), so I do not think it matters that much._https://www.blogger.com/profile/04508668132209394366noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-7154603103376929352012-01-17T15:48:35.935-08:002012-01-17T15:48:35.935-08:00IIRC you can use simpler to remember syntax-sugare...IIRC you can use simpler to remember syntax-sugared<br /><br><br />git push str --delete tag-for-czyżby<br /><br><br />with a --delete pseudooptionJakub Narebskihttps://www.blogger.com/profile/11847202568800326989noreply@blogger.com