git: no support for gpgsig tags
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Bazaar Git Plugin |
High
|
Unassigned | ||
| Breezy |
Medium
|
Jelmer Vernooij | ||
| Launchpad code imports |
High
|
Unassigned | ||
| One Hundred Papercuts |
Undecided
|
Unassigned | ||
| pyMOR |
Invalid
|
Undecided
|
Unassigned | |
| bzr-git (Ubuntu) |
High
|
Unassigned |
Bug Description
I'm trying to branch the xserver with bzr-git, and it's failing:
#: bzr branch git://anongit.
bzr: ERROR: Unknown extra fields in <Commit afc153a5b4fc58a
#: git show --show-signature afc153a5b4fc58a
commit afc153a5b4fc58a
gpgkeys: key 23C6CDF7272D9D43 not found on keyserver
gpg: Signature made Wed 09 May 2012 08:05:49 EST using RSA key ID 272D9D43
gpg: requesting key 272D9D43 from hkp server keyserver.
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: public key not found
Author: James Cloos <email address hidden>
Date: Tue May 8 17:55:10 2012 -0400
Fix RANDR’s gamma_to_ramp().
In order to generate a 256-entry ramp in [0,65535] which covers the full
range, one must mupliply eight-bit values not by 256 but rather by 257.
Many years back – well before the RANDR extension was written, and
before xorg@fdo – a similar bug fix was made to the DIX for converting
client-supplied eight-bit color values into sixteen-bit values.
Noticed by: Elle Stone and Graeme Gill.
Signed-off-by: James Cloos <email address hidden>
diff --git a/hw/xfree86/
index a773c34..aca0734 100644
--- a/hw/xfree86/
+++ b/hw/xfree86/
@@ -1679,11 +1679,11 @@ gamma_to_ramp(float gamma, CARD16 *ramp, int size)
for (i = 0; i < size; i++) {
if (gamma == 1.0)
- ramp[i] = i << 8;
+ ramp[i] = i | i << 8;
else
- * (double) (size - 1) * 256);
+ * (double) (size - 1) * 257);
}
}
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: bzr-git 0.6.9-1
ProcVersionSign
Uname: Linux 3.7.0-3-generic x86_64
ApportVersion: 2.6.2-0ubuntu5
Architecture: amd64
Date: Thu Nov 29 16:39:30 2012
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-06-16 (165 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120521)
MarkForUpload: True
PackageArchitec
SourcePackage: bzr-git
UpgradeStatus: No upgrade log present (probably fresh install)
Chris Halse Rogers (raof) wrote : | #1 |
summary: |
- bzr-git fails to check out xorg server: mishandles gpg-signed tags + no support for gpgsig tags |
Changed in bzr-git: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in bzr-git (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Jelmer Vernooij (jelmer) wrote : | #3 |
Basically what needs to happen is:
* in dulwich, extend Commit to serialize and deserialize gpgsig data (in dulwich/objects.py)
* in bzr-git:
- have all old mappings raise an exception if a gpgsigs are encountered (mapping.py)
- have new mapping convert gpg data into a bzr revision property and back
I think it'd probably a day or two if you're familiar with the git and bzr internals.
Hm. Given I'm familiar with neither the bzr nor the git internals, that
might be a bit longer for me then.
Don't let me block you from working on it ☺.
> Don't let me block you from working on it ☺.
FWIW I don't think bzr-git is actively maintained at the moment.
Changed in bzr-git: | |
status: | Triaged → Fix Committed |
Changed in bzr-git (Ubuntu): | |
status: | Triaged → Fix Committed |
Changed in bzr-git (Ubuntu): | |
status: | Fix Committed → Triaged |
Changed in bzr-git: | |
status: | Fix Committed → Triaged |
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in bzr-git: | |
status: | Triaged → In Progress |
Changed in launchpad: | |
status: | Triaged → Fix Committed |
Changed in bzr-git (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in bzr-git: | |
status: | In Progress → Fix Committed |
Jelmer Vernooij (jelmer) wrote : | #6 |
Hi Artur,
Please stop marking these bugs as fixed - they're not.
(I reverted the Launchpad bug state to New, since I can't set it to Triaged anymore)
Jelmer
Changed in bzr-git (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in launchpad: | |
status: | Fix Committed → In Progress |
status: | In Progress → New |
Changed in bzr-git: | |
status: | Fix Committed → Triaged |
Changed in launchpad: | |
status: | New → Triaged |
Harald Sitter (apachelogger) wrote : | #7 |
Making this non-fatal (on launchpad) would be rather helpful since as of a couple of days ago this is blocking KDE Frameworks 5 building [1]. Upstream is less than thrilled.
On Sun, Nov 03, 2013 at 10:07:36AM -0000, Harald Sitter wrote:
> Making this non-fatal (on launchpad) would be rather helpful since as of
> a couple of days ago this is blocking KDE Frameworks 5 building [1].
> Upstream is less than thrilled.
>
> [1] https:/
>
> ** Attachment added: "raw commit data of affected commit in kde-workspace"
> https:/
Unfortunately just ignoring these tags is not possible without
fundamentally breaking various assumptions in bzr-git.
bzr-git does a lossless conversion from git to bzr, so it can later
regenerate the exact same git objects. This is necessary since objects
sent by the server can be sent as deltas against fulltexts that the
server knows the client has.
If these tags are ignored, then bzr-git will be unable to reproduce
git commit objects with the exact same contents, and break.
Jelmer
More practically speaking, I think the most achievable solution is probably to run a manual fast-export/
Aron Xu (happyaron) wrote : | #10 |
Is there a way that can work around this bug and set up auto-import for a git repository that has some historical commits contain gpgsig? It seems that I'm not able to push to the branch set up by vcs-import, so fast-export/
On Tue, Nov 12, 2013 at 06:55:17PM -0000, Aron Xu wrote:
> Is there a way that can work around this bug and set up auto-import for
> a git repository that has some historical commits contain gpgsig? It
> seems that I'm not able to push to the branch set up by vcs-import, so
> fast-export/
Unfortunately that's not possible.
You should be able to sue fast-export/
branch.
Cheers,
Jelmer
same problem here: https:/
Changed in dulwich: | |
status: | New → Triaged |
importance: | Undecided → High |
Jelmer Vernooij (jelmer) wrote : | #13 |
See bug 1251682 for the relevant dulwich bug.
no longer affects: | dulwich |
John Vrbanac (john.vrbanac) wrote : | #14 |
Just ran into this issue a few days ago when a project I contribute to failed to sync because of a gpg signed commit:
You can find the log from launchpad in the attachment as well as in the following pastebin:
http://
Thomas Kluyver (takluyver) wrote : | #15 |
This is now preventing me from importing the matplotlib codebase to do nightly builds:
Peter Sabaini (peter-sabaini) wrote : | #16 |
I'm unable to import openstack/tempest because of this
Thanks for the replies.
At this point the issue is well documented; please don't add more examples of broken repositories.
I do not want to add another example, because there are already too many.
Just FYI, Debian is discussing right now the defaulting of gpg signed commits, so I guess this bug will be more and more important from now.
est31 (mtest31) wrote : | #19 |
Major git hosting service GitHub has just announced support for verifying signed git commits and tags [1].
Just noting, as this will most probably increase the usage of signed git commits.
[1] : https:/
Qwerty Chouskie (asdfghrbljzmkd) wrote : | #20 |
Just found this patched version: https:/
Could this get merged please? This bug breaks SuperTuxKart daily builds, see https:/
That fix is incomplete and possibly corrupts future pulls. See the bug report for an explanation.
On 13 June 2016 03:45:52 BST, Qwerty Chouskie <email address hidden> wrote:
>Just found this patched version:
>https:/
>Could this get merged please? This bug breaks SuperTuxKart daily
>builds, see https:/
>towards end.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I saw comment #8, but it does not seem like ignoring gpgsig tags should break deltas, as the code changes in the commits are the same...
Qwerty Chouskie (asdfghrbljzmkd) wrote : | #23 |
Also, the code change will defiantly not make anything worse, and might make things better, so it would make sense to merge it as a temporary fix... And, I tested the first section of the diff (https:/
Colin Watson (cjwatson) wrote : | #24 |
Our direction for this in Launchpad is to get git-to-git imports working (hopefully soonish), and then you can just use git-based recipes instead. This will be much simpler and more robust against all kinds of strangenesses in git repositories; for example, a fix for gpgsig is no help for the also-common problem that bzr-git doesn't handle submodules.
It will make things worse. People will get confusing errors (sha1 checksum or delta invalid exceptions), and bzr-git loses the ability to properly support the gpgsig tag.
On 13 June 2016 22:16:19 BST, Qwerty Chouskie <email address hidden> wrote:
>Also, the code change will defiantly not make anything worse, and might
>make things better, so it would make sense to merge it as a temporary
>fix... And, I tested the first section of the diff
>(https:/
>and it worked for branching SuperTuxKart
>(https:/
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I tried:
=== modified file 'mapping.py'
--- mapping.py 2013-09-02 00:54:58 +0000
+++ mapping.py 2016-06-13 04:07:10 +0000
@@ -333,7 +333,11 @@
if commit is None:
raise AssertionError(
if commit.extra:
- raise UnknownCommitEx
+ for (extra_key, extra_value) in commit.extra:
+ if extra_key == "gpgsig":
+ pass
+ sys.stderr.
+ else:
+ raise UnknownCommitEx
rev = ForeignRevision
But there was no output on the terminal, what am I doing wrong?
It will break deltas, as bzr-git won't be able to create the original git object anymore from the bzr data. The object it creates will lack the gpgsig tag and thus result in a checksum mismatch.
On 13 June 2016 21:29:38 BST, Qwerty Chouskie <email address hidden> wrote:
>I saw comment #8, but it does not seem like ignoring gpgsig tags should
>break deltas, as the code changes in the commits are the same...
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I made this patch: http://
It looks good, but nothing actually appears in the terminal or "~/.bzr.log". Maybe it only shows up if there is an error?
Are you fetching into a new repository and have you removed the bzr-git cache?
On 15 June 2016 01:24:10 BST, Qwerty Chouskie <email address hidden> wrote:
>I made this patch:
>http://
>It looks good, but nothing actually appears in the terminal or
>"~/.bzr.log". Maybe it only shows up if there is an error?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Where is the cache?
It depends on your system. Usually $XDG_CACHE_
On 16 June 2016 17:50:44 BST, Qwerty Chouskie <email address hidden> wrote:
>Where is the cache?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I checked ~/.cache, but there was nothing bzr-related there. I also checked ~/.bazzar/, but there was nothing cache-related there.
The cache could also be under the bzr repository somewhere.
On 16 June 2016 19:06:43 BST, Qwerty Chouskie <email address hidden> wrote:
>I checked ~/.cache, but there was nothing bzr-related there. I also
>checked ~/.bazzar/, but there was nothing cache-related there.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I deleted the whole repo before re-import, so that should not be the problem.
William Grant (wgrant) wrote : | #36 |
That patch won't do anything because you included the new check inside the "if commit is not None" block, which is an assertion that is meant to never fail.
Even if it was in the right place, however, it would try to raise None as an exception and crash.
If you fixed that, it would do as Jelmer says: create a corrupt branch that is unable to reproduce the commits that it says it can, because it won't store the gpgsig field that is needed for reconstitution.
This is fundamentally a very difficult dilemma, because you can't ignore the field: you either have to store it verbatim in a revision property, giving up the ability to implement it properly in future; or implement it properly, which it isn't at all clear how to do. Due to the way that git and bzr-git operate you can't just ignore it and hope it will work.
Changed in hundredpapercuts: | |
status: | New → Confirmed |
Changed in pymor: | |
status: | New → Invalid |
Jelmer Vernooij (jelmer) wrote : | #37 |
This is not a "trivial bug", which papercuts seems to be about.
Changed in hundredpapercuts: | |
status: | Confirmed → Invalid |
Rob Loach (robloach) wrote : | #38 |
This also has affected libretro-snes9x:
http://
bzrlib.
Rob Loach (robloach) wrote : | #39 |
Built ontop of wgrant's feedback, a new patch:
http://
While I understand the best way around this would be to implement the GPG signatures in bzr, but this is affecting many projects brought into Launchpad through bzr-git. Ignoring it may be the best option until we can implement it correctly in the bzr space.
Rob Loach (robloach) wrote : | #40 |
The attachment "bzr-git--gpg.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
tags: | added: patch |
Ignoring it will cause confusing import errors in incremental pulls for Launchpad imports as well.
Incremental pulls rely on deltas against full texts recreated from bzr data including PGP signatures. If even one byte in the full text is incorrect, that causes incremental pulls to fail.
On 19 July 2016 02:08:31 GMT+02:00, Rob Loach <email address hidden> wrote:
>Built ontop of wgrant's feedback, a new patch:
>http://
>
>While I understand the best way around this would be to implement the
>GPG signatures in bzr, but this is affecting many projects brought into
>Launchpad through bzr-git. Ignoring it may be the best option until we
>can implement it correctly in the bzr space.
Thanks for taking a look, Jelmer. Do you have an idea of a way forward with it? William mentioned he was unsure of how to do it properly.
On Tue, Jul 19, 2016 at 05:56:28PM -0000, Rob Loach wrote:
> Thanks for taking a look, Jelmer. Do you have an idea of a way forward
> with it? William mentioned he was unsure of how to do it properly.
They are the equivalent of testaments, so ideally they should be
converted to those. I don't recall enough about testaments to know
whether that would actually work though.
Alternatively, they could just be stowed in bzr revision properties
and then reimported whenever bzr revisions are converted to git
commits.
Jelmer
Adding a note to mention that this bug makes is quite difficult to use the PPA with Github repositories. I wanted to try to build my own .deb for Jabref, so I started by trying to import the code from the Jabref github pages. Here is where I got to:
https:/
However, when importing from Github, there is an error from Launchpad, specifically from "/srv/importd.
A little surprised by this... surely other people are importing code from Github?
Cheers
JP
2016-08-03 02:07:49 INFO Starting job.
2016-08-03 02:07:49 INFO Getting exising bzr branch from central store.
2016-08-03 02:07:50 INFO [chan bzr SocketAsChannel
2016-08-03 02:07:50 INFO [chan bzr SocketAsChannel
2016-08-03 02:07:50 INFO 285 bytes transferred
2016-08-03 02:07:51 INFO Importing branch.
2016-08-03 02:07:53 INFO Counting objects: 118432, done. 0
2016-08-03 02:08:53 INFO 68240614 bytes transferred | Compressing objects 3/3
2016-08-03 02:09:05 INFO finding revisions to fetch:generating index 0/118432
2016-08-03 02:09:26 INFO finding revisions to fetch:generating index 0/118432
2016-08-03 02:09:38 INFO finding revisions to fetch 1/3
2016-08-03 02:09:38 INFO
Traceback (most recent call last):
File "/srv/importd.
sys.
File "/srv/importd.
return import_worker.run()
File "/srv/importd.
return self._doImport()
File "/srv/importd.
inter_
File "/srv/importd.
self.
File "/srv/importd.
determine_
File "/srv/importd.
limit)
File "/srv/importd.
mapping.
File "/srv/importd.
raise UnknownCommitEx
bzrlib.
Import failed:
Traceback (most recent call last):
Failure: twisted.
Colin Watson (cjwatson) wrote : | #46 |
John, it has nothing to do with whether you're importing from GitHub; it depends on whether the repository's history contains commits with gpgsig tags.
Our plan for this remains as I outlined in comment 24, although some other urgent bits of work have jumped the queue and delayed us implementing it. A workaround for the time being might be to occasionally push the git repository to Launchpad's own git hosting manually.
Robert Bruce Park (robru) wrote : | #47 |
lp:emacs is bit by this bug since April 2016. I'm eagerly awaiting those git-to-git imports ;-)
Colin Watson (cjwatson) wrote : | #48 |
Launchpad git-to-git imports are available now: http://
Great news! Is there also a issue report here on Launchpad for the nest-part implementation for git recipes? Would like to get notified when it's there.
Colin Watson (cjwatson) wrote : | #50 |
Thomas: I implemented that a while back (bug 1537579), but just forgot to update the documentation. I've done the latter as well now.
Awesome! Many thanks, Colin!
Changed in brz-git: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Mystic-Mirage (mystic-mirage) wrote : | #52 |
Same error while trying to import GitHub repo -- https:/
The latest commit is marked as "Verified" by GitHub and import fails.
https:/
http://
Jelmer Vernooij (jelmer) wrote : | #53 |
brz-git can now import and preserve signatures (but won't create them on git commits you create from within breezy).
Changed in brz-git: | |
status: | Triaged → Fix Released |
assignee: | nobody → Jelmer Vernooij (jelmer) |
Changed in brz-git: | |
milestone: | none → integration |
affects: | brz-git → brz |
Changed in brz: | |
milestone: | integration → none |
milestone: | none → 3.0.0 |
summary: |
- no support for gpgsig tags + git: no support for gpgsig tags |
affects: | launchpad → lp-codeimport |
Do you have an estimate of the complexity of fixing this? It's semi-blocking something that I need to work on, so if it's likely to be doable by someone with no prior bzr-git experience I'd be able to hack on it.