[12:28] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Override plone.css radiobutton silliness (bug 2586) (patch-2616: mpt@canonical.com) === mgalvin [n=mgalvin@cpe-69-205-47-165.nycap.res.rr.com] has joined #launchpad === cprov goes home [01:12] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fix https://launchpad.net/products/launchpad/+bug/2662 (PersonAccountToMergeVocabulary() contains the person that is logged in) (patch-2617: guilherme.salgado@canonical.com) === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad [01:29] Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-81) [01:30] Merge to thelove@canonical.com/bazaar--devo--1.5: [Fixes #78] Add some message before prompting for signature [aldrik.kleber@tiscali.fr--public (patch 0-4)] (patch-65: aldrik.kleber@tiscali.fr, Matthieu.Moy@imag.fr) === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad [01:36] stub: ola [01:36] stub: can you point me at the scripts you have written that use baz ? [01:36] heya stub [02:10] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fix https://launchpad.net/products/launchpad/+bug/2663 (Confusing text mislead user to think both account passwords are required when merging accounts) (patch-2618: guilherme.salgado@canonical.com) === mpool [n=mbp@ozlabs.org] has joined #launchpad [02:56] lifeless: The Makefile.staging in dists--devel--0. Also 'rocketmeld.py' in the utilities directory of launchpad [02:56] morning stub [02:56] stub: I ask, cause I need to bzrify them [02:56] stub: unless you would like too :) [02:57] is this the right channel for foodix reports? [02:58] lifeless: Don't worry about rocketmeld.py. The staging Makefile would be trivial (it just does a checkout). [02:58] stub: ok. [02:58] i have ended up with 1:6.2.1+cvs.20050722-7 installed, but it's not present in the archive [02:58] i might have got that from the non-foodix copy of breezy === TimM [n=none@b-6c.lcom.net] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [03:30] Kinnison: ^^^ mpools lines ^^^ === TimM [n=none@b-6c.lcom.net] has left #launchpad [] [03:42] mpool, you're using dogfoodix, then? === GoRoDeK [n=gorodek@p5083D72C.dip.t-dialin.net] has joined #launchpad [03:44] stub: are you around ? [03:44] bah [03:44] SteveA: are YOU around ? [03:44] I am [03:45] but SteveA isn't for sure [03:45] thanks [03:45] kiko-fud: yes i am [03:45] mpool, does it require much bravery? [03:45] uh, should it? [03:45] i don't feel very brave [03:46] i just do as i'm told [03:52] lifeless: yo [03:52] stub: unping [03:52] I wanted the other stub [03:53] unpong === stub wanders off to the shower === segfault [i=carlos@prognus.com.br] has joined #launchpad === freeflying [n=rockie@61.190.65.16] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [06:05] feh === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === mpool [n=mbp@ozlabs.org] has left #launchpad [] [06:40] Merge to rocketfuel@canonical.com/launchpad--production--1.36: Cherry pick patch 2612 into production 1.36 (patch-4: rocketfuel@canonical.com, guilherme.salgado@canonical.com) === terrex [n=terrex@84-122-90-162.onocable.ono.com] has joined #launchpad === BjornT [n=bjorn@84.32.140.183] has joined #launchpad [07:56] good morning [07:56] lifeless: ping? === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad [08:01] jamesh: pong [08:03] lifeless: w.r.t. your comment on my bug-74 branch, if I switch to "abbreviated_textdir" on the content class, do I have r=lifeless? [08:03] oh yes [08:03] btw, you know that pendingreviews is failing tests ? [08:03] yeah [08:04] I need to do some more extensive changes to handle branches-with-the-revision-number-set, but didn't fix up the problems in the bzr version (will fix it soon) [08:07] ok [08:07] I plan to rollout pqm-bzr this week [08:08] the test suite error looks a bit weird because the __eq__ method is catching AttributeError [08:09] yes [08:10] it was obvious what the issue is :0 === henrym [n=henrym@219-89-147-70.jetstart.xtra.co.nz] has joined #launchpad [08:43] jamesh, lifeless: So about this gpg tool thingy. Daniel wants gina running on production, like, tomorrow and I would prefer to run this thing before that. [08:49] 17:29:09) stub: jamesh: yes. People need to be able to create and edit their own hackergotchi (there was an email on this which I can't locate) [08:49] (17:29:54) stub: jamesh: Did the GPG web-o-trust stuff land, and if so what should I run on staging? [08:49] (17:32:58) James Henstridge: stub: there are two scripts -- the first of which needs access to the gpg strongly connected set and list of trusted keys [08:49] (17:33:16) James Henstridge: the second is responsible for updating the database, and uses the output of the first script [08:49] (17:33:40) James Henstridge: stub: lifeless would know what data to use for the first one [08:49] (17:34:18) stub: ok. so the first script needs to only be run once anywhere and we can use the output on staging, and if we are happy with the result, production [08:49] (17:34:47) James Henstridge: yeah [08:50] lifeless: whereabouts would I get the strongly connected set data to do a run of the script? [08:50] (and which keyrings do we treat as trusted? [08:51] jamesh: search me [08:51] trusted, ubuntu-keyring, debian-keyring [08:51] ubuntu-keyring has two keys in it on my system === dda1 [n=ddaa@ordo.xlii.org] has joined #launchpad [08:52] "Ubuntu Archive Automatic Signing Key" and "Ubuntu CD Image Automatic Signing Key" [08:52] mm [08:53] apt-cache search keyring perhaps === azeem_ [n=mbanck@host109.natpool.mwn.de] has joined #launchpad === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [08:58] lifeless: are we able to get a dump from our local keyserver? [08:58] Can we just use one of our own keyrings? [08:58] jamesh: I imagine so [08:58] these are some of the PGP bits I'm not versed in [08:58] jamesh: but I have not been involved with the keyserver foo === freeflying [n=rockie@61.190.65.16] has joined #launchpad [09:02] So it sounds like a tool has been written without thought on how it is supposed to be run :-/ [09:04] stub: lots of though [09:04] stub: we know what format the things we get will be in , and for 2/3 of them we knew where to get them [09:04] jamesh: a dump of a keyserver is approx 4GB... [09:05] fabbione: we just want the strongly connected set [09:05] just abuse the server.. it's better for the few keys you need compared to the 2.5M in there [09:05] But this tool is supposed to *calculate* that [09:05] stub: no, its not. [09:05] lifeless: just start from my or your key and grab them.. they are about 22K iirc [09:06] stub: its supposed to use the debian + ubuntu 'trusted keys', plus relationships spidering out from there within the SCC, to establish with some degree of confidence that user A and user B are the same person [09:06] stub: if we wanted the SCC alone, we would not have written code. [09:06] I call that calculating a trusted set of keys. [09:07] lifeless: anyway to get a full dump, you need to stop the keyserver [09:07] stub: a trusted set of keys is not the strongly connected set. [09:07] stub: it starts with a trusted set of keys, and ends up with a trusted set of (key, uid) pairs [09:07] stub: the SCC/SCS is a different beast to what we are calculating. [09:07] Indeed. I never said SCC or SCS. I don't even know what those abbreviations stand for. [09:08] stub: the starting conditions are "keys owned by people we trust to make good signing decisions", and the second is "(key, uid) pairs we are confident are correct" [09:08] stub: well, I'll stop this thread, except to note it started when I said 'we need the scc, and you said 'its meant ot calculate that'' [09:08] strongly connected set == a set of nodes that can all reach each other via the directed edges between the nodes [09:09] "the" strongly connected set would be the big one in the PGP web of trust [09:10] we're interested the one around debian/ubuntu though, which is the same one IIRC [09:10] Anyway. I still need to know how to run this tool. So far all I'm hearing is that it is not ready yet, because a part of the chain is missing. [09:10] As it doesn't build its own keyring, someone needs to build one for it. And I doubt the 4GB full dump is appropriate. [09:11] jamesh: are you looking for a scc at the moment ? [09:11] lifeless: I haven't started yet. Should I try Fabbione's idea? [09:12] jamesh: there are precanned ones, I suggest goodle [09:12] How can we trust a precanned one? [09:12] by the signatures in the debian and ubuntu keyrins [09:12] *keyrings* [09:16] So we trust a precanned SCC if it has been signed by a key in the debian or ubuntu keyrings? [09:17] That would indicate it has been manually uploaded and signed, which would be out of date. So crawling our own keyserver would be the better approach. === azeem [n=mbanck@host45.natpool.mwn.de] has joined #launchpad [09:18] stub: its not *that* dynamic a thing [09:18] but, if you want to, http://www.dtype.org/keyanalyze/code/ [09:20] Oh - do we actually *need* to trust that the SCC we use is acurate, or does our code verify if each key in the keyring is trusted enough for our purposes? [09:20] the latter [09:20] the only keys we *actually trust* are the ubuntu and debian ones. [09:21] at least, as I understand it from when I was working on it. [09:21] jamesh should be able to confirm [09:21] trusting random people who happen to have had their key signed and signed someone elses would be rather dumb. [09:22] lifeless: yeah. only the keys on keyrings passed with --trust have their ownertrust value set. [09:22] gpg does the rest [09:22] And I assume that the code actually *does* need the keyring prebuilt and there is no magic option to the GPG library we are using to pull down unknown keys from the keyserver? [09:23] stub: it will pull unknown keys automatically [09:23] but that is relatively slow [09:23] its preferred to have as much pre-seeded as possible [09:23] So all we need is any one of our keys and we can run it. [09:23] (because each key we add needs another trustdb rebuild and that is not incremental) [09:24] yech. [09:24] stub: install the debian-keyrin and ubuntu-keyring packages, or extract the keyrings from them [09:24] stub: then you have the bare minimum [09:24] let me see about an ubunut accurate list [09:27] I still havn't the foggiest idea what actually needs to be run. Anyone care to tell me what the scripts are called? Is it 'scripts/find-email-clusters.py' ? [09:27] ok - that looks like it. [09:28] stub: yeah. you'd run "find-email-clusters.py --trust trusted-keyring.gpg scc.gpg" [09:29] jamesh: scripts and cronscripts should have 'import _pythonpath' as the first import because I'm too lazy to set PYTHONPATH explicitly [09:29] you can specify multiple trusted keyrings by repeating the --trust option, and multiple untrusted keyrings as positional args [09:30] So where can I find the ubuntu and debian keyrings? [09:30] "apt-get install debian-keyring ubuntu-keyring" [09:30] and they'll be in /usr/share/keyrings/ [09:31] No apt get here - I don't have root ;) === stub looks for it on chinstrap [09:32] nope. [09:32] bah [09:33] morning all [09:33] gmorning [09:33] stub: http://ftp.debian.org/debian/pool/main/d/debian-keyring/debian-keyring_2005.05.28.tar.gz should be it === GoRoDeK [n=gorodek@p5083FCF1.dip.t-dialin.net] has joined #launchpad [09:33] stub: jamesh: ubuntu keyring needs elmo to export it. I suggest trialling it without it for now [09:34] I just need to extract the debian keyring locally and upload it since it doesn't seem to exist on the machines I have access to [09:34] This should have all been hardcoded in the script :-/ [09:35] stub: the tarball I gave the URL to should have it [09:35] (I think) [09:35] jamesh: How do we trust it? [09:36] stub: check the signature in the dsc file [09:36] the keyrings md5 sum is signed by elmo [09:36] stub: alternatively, pull it from the Ubuntu repository [09:36] jamesh: That involves doing it all locally again ;) [09:36] The rsync area on keyring.debian.org is the canonical location for [09:36] keyrings and it is what the Debian installer program (dinstall) uses. [09:36] If your key is available from there, it will be seen by dinstall. The [09:36] tarball and Debian package are provided for user convenience and are [09:36] not necessarily in sync with keyring.debian.org. [09:36] That file contains the keyrings, signed copy of keyring md5sums and [09:36] this README. The keyring md5sums will be signed by James Troup. [09:37] lifeless: please review importd-archivelocation today [09:37] ddaa: yes [09:37] it's a prerequisite for niemeyer starting fixing import for branchdatastorage [09:37] ack [09:37] I dont do it, you block, we all suck. [09:37] not yet quite blocked on it [09:40] Once we have run this, who can check that it has done what it is supposed to? [09:46] jamesh, lifeless: ^^^ [09:51] It is bombing: https://chinstrap.ubuntu.com/~dsilvers/paste/file3NPAqW.html [09:56] stub: did you pass a non-trusted keyring? [09:56] It did the samething when I did [09:56] lifeless: for a fast import you can disable the --check-trustdb option [09:57] lifeless: and run it manually at the end of the import [09:57] stub: ah. try replacing ~ with $HOME, maybe? [09:57] fabbione: we already do that [09:58] eh? I thought bash did that for me ;-/ [09:58] I'm guessing [10:00] Hmm... seems to be running now. === stub kills gina [10:01] bombed out again. it is doing *something* though before it bombs. [10:07] Still running this time... [10:11] Should I be running this with '-v' ? [10:13] jamesh: I believe parser.error('the error') is the badly documented yet preferred method of raising an error on bad command line arguments === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [10:23] hi [10:23] lifeless: did you want something? [10:29] SteveA: advice on some evil python stuff [10:29] that I was unsure about doing [10:31] I have 3790 lines of output from the find-clusters.py script. Does that sound correct? [10:39] I think I'm going to have to give up on this until someone-who-knows can help running this stuff on staging and confirming that it works and run gina without it (which is a shame, because we have been blocking gina since brazil for this :-( ) [10:44] Good Morning all [10:45] stub: it should be groups of email addresses separated by blank lines [10:45] jamesh: it is. but should I have 10 or 1,000,000? [10:46] stub: would depend on how many keys you looked at. Was this just the debian keyring? [10:47] jamesh: I ran it with the debian keyring as the trusted keyring, and a copy of the debian keyring as the strngly connected set. [10:48] stub: then that sounds like about the right amount of data [10:48] a quick check shows ~ 3500 unique uids in that keyring, all of which would be considered valid if you trust all those keys [10:49] jamesh: but what about all the other keys that we infer trust for? [10:49] stub: if you ran it without any other keys, then there is no other keys to infer trust for. [10:50] There is a whole keyserver to interrogate. 4GB of keys. [10:50] (17:23:13) Robert Collins (lifeless): stub: it will pull unknown keys automatically [10:54] I think he was talking about http://www.dtype.org/keyanalyze/code/ [10:55] argh. So I've wasted the last hour or so, because my original impression was correct and the code isn't yet useful to us. [11:02] stub: so, my merge didn't go through last night. i'm going to try again, but i don't want to conflict with your browser messages stuff. [11:04] ddaa: we should talk about the python import, and 32k === ddaa looks for some run-off-the-mill "we should talk" housewife rebuttal [11:05] eeeer, yes honey? [11:06] i don't think a importing a sticky sweet python will help anyone [11:06] do you mean it should be less sticky? [11:06] (whatever that means) [11:06] honey is sticky regardless. [11:07] let's avoid absurd jokes... === sivang read that sentence literally. [11:07] SteveA: so, what with the goddamn python import? [11:08] so, you checked out apache and other tools, that they can handle 32k subdirectories [11:08] you need to decide with lifeless about whether it needs to be available on the supermirror [11:08] then, we need to decide on what size partition on what machines to request === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [11:08] Yes. [11:09] hi [11:09] hello carlos [11:09] SteveA, I'm with the gas installation, they are taking much more time than I expected [11:09] okay [11:09] carlos: please see the email from Timo Jyrinki [11:09] ok === henrym [n=henrym@219-89-147-70.jetstart.xtra.co.nz] has left #launchpad ["Leaving"] [11:09] on rosetta-users [11:09] I did not check very thoroughly, but the toolchain is only using stuff that's so standard it should have no problem with large number of subdirs. [11:11] One bit that might be worth checking though is the backup tool, but it's outside of my control. [11:11] if anything else break, I'll happily offer large amounts of beer to annoyed parties [11:12] if the backup tool doesn't work, we'll just need to work without backups until we get a proper bzr backend [11:12] or use different, less frequent backups "by hand" [11:14] So, you want me to send clarifications about publishing requirements and disk space requirements? [11:14] to you and elmo? [11:15] Anything else? [11:18] i think that's all. and where you want the partition's mountpoint to be [11:19] exactly what machines it needs to be on [11:19] stub, is staging being updated every day? [11:19] yes [11:20] SteveA: okay, I'll get clear requirements from lifeless (writing email now). [11:21] stub: i'm merging my LaunchpadBrowserRequest thing with pqm now [11:22] SteveA: ok [11:22] SteveA: is that the thing we talked about yesterday? [11:22] ddaa: it makes things easy for the traversal code you need to write, yes [11:23] I'm starting to block on it (I can still work on pending sql pach work for a day or so) [11:25] ddaa: so, once pqm has done its stuff, i'll switch to your branch, and send you a patch that does the things you need [11:25] Lovely. [11:41] stub: SQL trivia [11:41] SteveA, I really need the review for my language pack branch [11:41] SteveA, would that be possible? [11:41] sure [11:42] is it ready on the pending reviews page? [11:43] yeah [11:43] I have a Branch table, with a foreign key started_at to RevisionNumber. And RevisionNumber has a foreign key branch to the Branch table. How do I add a constraint so that branch.started_at.branch == branch? [11:44] carlos.perello@c.c--2004/launchpad--language-pack-export--1 [11:44] SteveA, yeah [11:46] (where started_at can be NULL) [11:47] ddaa: Generally you don't [11:48] stub: I guess you could use a procedural constraint. How do you generally draw the line here? [11:49] ddaa: I think it depends on how many different components of our systems need to update those tables. [11:49] mh [11:50] RevisionNumber would only be updated by Taxi. But Branch.started_at could be updated by any number of components, including the web UI. [11:50] ddaa: We can do it with a trigger, but I doubt the extra complexity is worth it if we can be fairly sure the code that updates those tables do the right thing. [11:51] Bah... I guess I could add an assert in the database class. === freeflying [n=rockie@61.190.65.16] has joined #launchpad [11:52] stub: thanks [11:55] carlos: have you checked out the database stuff in that branch with stub? === peterbe [n=peterbe@62.232.38.28] has joined #launchpad [11:57] ddaa: I think we can do it with a foreign key constraint. If you paste what you have I can update it. It involves making RevisionNumber(branch, id) UNIQUE and declaring a FOREIGN KEY (id, started_ad) REFERNECES RevisionNumber(branch, id) on Branch [12:00] stub: you rock [12:00] hmm [12:00] SteveA, I don't remember it.... === carlos takes a look to the branch === jinty [n=jinty@205.134.224.215] has joined #launchpad [12:02] SteveA, stub, do we need to check the additions to the security file? [12:03] didn't know that... [12:03] they look like the minimum you need [12:03] stub: here's what the patch currently looks like [12:03] https://chinstrap.ubuntu.com/~dsilvers/paste/fileHhw8IB.html [12:03] no garantee it's even valid sql at this point :) [12:05] I'm not sure the extra UNIQUE constraint is really necessary as RevisionNumber.id is already unique (being a primary key), but maybe postgres requires it. [12:06] ddaa: The extra UNIQUE on the two columns is required to allow a foreign key reference to those two columns [12:08] there's a TODO in the patch at the place where I think the constraint shoud be added (but you own that anyway...) [12:15] Who here knows about the GPG interface in launchpad? === shawarma [n=sh@3E6B503C.rev.stofanet.dk] has left #launchpad [] [12:18] can someone check to see if pqm has hung? [12:19] Kinnison: UI or IGPGHandler stuff? [12:19] jamesh: the latter === Kinnison wants to know if there's an easy "I have a 64bit keyID, can you give me, 1. the key and 2. the Person who owns it" type interface [12:21] I think I can get the Person record reasonably easily [12:21] but I need to know how to extract the key using the launchpad infrastructure [12:22] I need the literal key data for the gpg verification stuff for package uploads === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [12:23] Kinnison: getUtility(IGPGHandler).retrieveKey(keyid) seems to work for short IDs as well as fingerprints [12:23] doing an import if necessary [12:23] ddaa: You are deleting the contents of Branch, but there are rows in ManifestEntry that reference stuff in there. [12:24] erm... c/Branch/Revision [12:24] Kinnison: of course, if you have the Launchpad person, you should have full fingerprints for the user's keys === Seveaz [n=seveas@seveas.demon.nl] has joined #launchpad [12:24] jamesh: I have a 64 bit keyid, that's *IT* [12:25] Kinnison: is this keys not registered in Launchpad then? === stub confuses himself [12:26] jamesh: it might be in launchpad, I don't know yet [12:26] jamesh: I've just been presented with a clearsigned text file [12:26] jamesh: I can get the keyid from that [12:26] jamesh: from there, I have to find everything else out, including whether or not the file was tampered with [12:27] stub: I'm pretty sure I checked out with Keybuk about that... [12:28] making a full update would be a big pain :( [12:28] Kinnison: okay. There are two interfaces here: the IGPGHandler stuff will let you retrieve the key (from the keyserver), and can do so by the short ID [12:28] stub: I have to go to lunch now, back in about 45 mins [12:28] Kinnison: the IGPGKeySet interface lets you see keys the Launchpad database knows about [12:29] jamesh: will the IGPGHandler literally give me the key as a string? [12:30] Kinnison: it gives you an object representing the key, so you can get its fingerprint, uids, etc [12:30] ddaa: There are only 4 manifestentries on production [12:30] jamesh: I want, quite literally, the keydata [12:31] jamesh: *OR* I want to know the full path to the keyring that the IGPGHandler has just imported a key into [12:31] jamesh: which of those two can be supplied? [12:32] Kinnison: the keyring would be $GNUPGHOME/pubring.gpg [12:32] jamesh: thanks. [12:33] jamesh: and that's configured, simply by doing blah=getUtility(IGPGHandler) ? [12:33] jamesh: or do I have to do something to set stuff up before I can rely on $GNUPGHOME/pubring.gpg being present? [12:33] Kinnison: are you sure the IGPGHandler.verifySignature() method wouldn't be appropriate? [12:34] The import stuff has a very very very specific wrapper around the gpgv implementation [12:34] at this point in the game, I don't want to not use it [12:34] elmo trusts the handler I have, it's important not to lose that level of trust to begin with [12:35] Or are you telling me that I can simply ask the IGPGHandler to verify a bit of clearsigned content and it will not only tell me whether or not it is valid, but who signed it etc, without first being primed with the key? [12:36] let me do a quick check [12:38] carlos: reviewed [12:38] Kinnison: gpg = getUtility(IGPGHandler); sig = gpg.verifySignature(clearsigned_data) [12:38] Kinnison: sig.fingerprint is the fingerprint, sig.plain_data is the associated data [12:39] jamesh: even without feeding it keys first? [12:39] Kinnison: the gpg config is set to auto-key-retrieve [12:39] right [12:40] and then I can do getUtility(IGPGKey).selectBy(fingerprint=sig.fingerprint) [12:40] yes? [12:40] yep [12:40] well, IGPGKeySet [12:40] and getByFingerprint() [12:41] if you get a key record, you can then get the person object [12:41] cool, ta [12:42] ddaa: ping [12:42] jamesh: and if it's unable to get the key? [12:42] jamesh: or if the data is damaged? [12:43] Kinnison: the key record? [12:43] Kinnison: if IGPGKeySet.getByFingerprint() returns None, then the key has not been registered in launchpad [12:43] jamesh: consider a clearsign by a key never uploaded to the keyserver [12:43] jamesh: such that the gpg instance can't fetch it [12:44] Kinnison: then the signature verification would fail [12:44] Kinnison: but all keys registered in the Launchpad database come from the keyserver network [12:44] (the registration process asks you for the key fingerprint, and then retrieves the key from the keyserver) [12:46] jamesh: aye, but we have to consider uploads from people who are not registered and fail gracefully [12:46] jamesh: so what happens if the verification fails? do I get "None" back? a reason, or an exception raised? [12:46] Kinnison: that would be a policy decision. [12:47] Kinnison: yep. If the verification fails, verifySignature() returns None [12:47] urgh [12:47] no reason? [12:47] SteveA, thanks [12:47] nope [12:47] not good enough then [12:48] lifeless: ping [12:48] where is the implementation of IGPGHandler? === Kinnison will have to augment it to return a reason [12:48] ctags [12:48] lib/canonical/launchpad/utilities/gpghandler.py [12:48] jamesh: ta [12:48] the other half is pyme :) [12:48] idtools ;-) === jamesh thinks pqm has hung [12:50] looks like pqm 398 0.0 0.0 2280 860 ? S 10:53 0:00 nc -l -p 2401 -e /home/pqm/arch/queue/workdir/rocketfuel@canonical.com/rocketfuel@canonical.com---launchpad--devel--0/launchpad/sourcecode/cscvs/,,repoCatalog/CVSROOT/server [12:51] lifeless, ddaa: looks like some cscvs stuff is hanging pqm [12:52] Kinnison, do you require sign-only keys to work? [12:53] kiko: given that the key has to be in launchpad for verification and identification, I'll be happy with whatever makes it into launchpad [12:53] I'd like for signing-only to work [12:53] Kinnison, yeah, bug 1972 would be great to fix [12:53] Malone bug #1972: Problem validating sign-only GPG key Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Celso Providelo, Status: Accepted http://launchpad.net/malone/bugs/1972 [12:53] jamesh, would you be able to help us debug 1972? [12:53] wow [12:53] kiko: It may be essential for the distro team [12:53] who develop Ubugtu? [12:54] jamesh, it requires some gpgme research, I think [12:54] carlos, Seveaz [12:54] cool [12:54] kiko: I added a comment a few hours ago. Does it sound like a possible reason? [12:55] let me check === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #launchpad [01:02] jamesh, that's an analysis of the second part of the problem [01:02] jamesh, I'm going to file a new bug on it [01:02] jamesh, I'm asking more about the fact that sign-only keys don't work [01:04] kiko: that they don't work for op_encrypt(), or that we offer no method to register such keys? [01:07] jamesh, I think the latter is intractable :-) so it's the former. === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad === Albaraha [n=Albaraha@82.194.43.173] has joined #launchpad [01:15] err sorry [01:15] the opposite, jamesh === carlos thinks he lost some code at some point === camilotelles [n=Camilo@20132203203.user.veloxzone.com.br] has joined #launchpad [01:19] kiko, didn't you asked me to change the validation function from helpers to potmsgset a couple of weeks ago? [01:22] stub: SteveA: back [01:22] kiko: okay. First thing we need to do is expose subkey information on IPymeKey instances. That'll give us can_encrypt, can_sign, etc attributes for each subkey [01:23] kiko: if a key has no encrypting subkeys, then we'll need to fall back to a separate "signing key" registration scheme like what Kinnison described in the bug [01:24] stub: manifestentry.changeset is always NULL [01:25] kiko: we'd probably want to note the fact that a key has only been registered for signing in the gpgkey table (an extra bool column should do) [01:25] therefore I can safely delete all changeset/revision records [01:25] ok [01:26] kiko: actually, we won't necessarily have to expose all the subkey information -- we can just have a key-level can_sign, can_encrypt, etc attributes [01:26] calculate those once [01:26] jamesh: lifeless has reset pqm. stub, elmo and znarl also know how to do this and have rights to do so, for future reference [01:27] carlos, I did, yes. [01:27] carlos, and AIUI you did it! [01:27] I know [01:27] but the language pack branch lacks that change [01:27] and last merge with rocketfuel was last week... [01:28] so I wonder if I have an unmerged branch... [01:28] jamesh, but how are we going to validate the key if we can't encrypt? only by using a scheme such as Kinnison suggested. [01:28] ah [01:28] that's what you're saying. [01:28] jamesh, that sounds perfect [01:29] jamesh, could you cook up a patch? as soon as that's landed we can work on registering sign-only keys [01:30] kiko: sure. [01:30] kiko: do you want subkey information available, or just the summary can_sign,can_encrypt,etc attributes? [01:30] or both? [01:34] jamesh, hmmm. I don't think I need the subkey for anything -- I just need to be able to encrypt or sign content depending on the capability of the subkeys -- so just the summaries are fine. Kinnison, do you need specific subkey information? [01:34] kiko: we won't be able to encrypt or sign the message to the owner of a sign-only key (unless we are signing with a "launchpad" key) [01:35] kiko: we can only verify the signatures made with that key [01:36] stub, hi, around? [01:36] yes === camilotelles [n=Camilo@20132203203.user.veloxzone.com.br] has left #launchpad ["Leaving"] [01:37] stub, about my request to change the rawimportstatus field [01:37] stub, why do you think we need to reset the rawfile field? [01:37] jamesh, err, yeah, what you said [01:39]