2016-06-13 03:55:30< HarveySpectre> dol-sen: dol-sen|work: http://codepad.org/oRkQaze0 with this change, I'm able to get this: http://codepad.org/d8OR37zV
2016-06-13 03:56:28< HarveySpectre> Sorry about the delay and introducing the regression in the first place. Is there any more weird behaviour happening or was this all?
2016-06-13 04:01:30< HarveySpectre> Just thinking if ("FPR", COLON_LISTING_FIELDS[:8] + ['fingerprint'] + [COLON_LISTING_FIELDS[10]], "Fingerprint") should be extended to cover the whole COLON_LISTING_FIELDS list.
2016-06-13 04:12:17< HarveySpectre>     ("FPR", COLON_LISTING_FIELDS[:8] + ['fingerprint'] + COLON_LISTING_FIELDS[9:11] + ['issuer_fingerprint'] + COLON_LISTING_FIELDS[12:], "Fingerprint") seems to be the best option as it handles everything.
2016-06-13 04:23:49 * HarveySpectre will do a pull request to dol-sen's repo once we decide it..
2016-06-13 05:17:56<@dol-sen> HarveySpectre, there was a few others that were not consitent with the others too
2016-06-13 05:18:38<@dol-sen> which means you needs to have essentiall y the same as I had before, but organized to your new style
2016-06-13 05:34:56< HarveySpectre> dol-sen: ok, I'll dig up all the differences and modify legend.py accordingly. Regarding the fingerprint, which version do you think is better? The shorter one or the full length one?
2016-06-13 05:35:26<@dol-sen> well, it doesn't do more than the 0-10
2016-06-13 05:35:44<@dol-sen> there is no point adding more foelds to the data record
2016-06-13 05:35:53<@dol-sen> only fingerprint is used anyway
2016-06-13 05:36:20<@dol-sen> there is already 9 empty ones
2016-06-13 05:36:24< HarveySpectre> dol-sen: from the DETAILS file, *** Field 13 - Issuer certificate fingerprint or other info
2016-06-13 05:36:24< HarveySpectre>     Used in FPR records for S/MIME keys to store the fingerprint of
2016-06-13 05:36:24< HarveySpectre>     the issuer certificate.
2016-06-13 05:37:04<@dol-sen> I think I'd like to clean those up, but having them means it may be better if they actually start putting data in those unused ones
2016-06-13 05:37:39<@dol-sen> if there is a possibility of other data, then add them
2016-06-13 05:39:06< HarveySpectre> dol-sen: yes, for future version compatibility..which was the whole point of sanitizing legend.py with a common format.
2016-06-13 05:39:16< HarveySpectre> 9 empty fields never hurt Python IMHO :D
2016-06-13 05:39:25< HarveySpectre> but it's certainly wasted space
2016-06-13 05:39:30< HarveySpectre> at least at the moment
2016-06-13 05:39:36<@dol-sen> yup
2016-06-13 05:40:10<@dol-sen> it isn't like we need 10,000 of them stored in memory during the run
2016-06-13 05:40:50< HarveySpectre> yes, so following a standard (but a little inefficient) approach is a good way out?
2016-06-13 05:41:02<@dol-sen> yeah
2016-06-13 05:41:22<@dol-sen> is more flexible if upstream gnupg add extra data to them
2016-06-13 05:59:03< HarveySpectre> Regarding UAT, before my changes, it was set to not using the User-ID class but calls it 'signature' instead. But in the DETAILS file: "A UAT record puts the attribute
2016-06-13 05:59:03< HarveySpectre>     subpacket count here, a space, and then the total attribute
2016-06-13 05:59:03< HarveySpectre>     subpacket size." Isn;t that a bad choice of a name?
2016-06-13 05:59:21< HarveySpectre> user-ID field*
2016-06-13 06:02:04< HarveySpectre> I compared the revs, looks like only UAT and FPR were affected by my changes. Completely missed the fact that they do this extra magic too. Just fixed the hacks in output parsing with those changes.
2016-06-13 07:33:54< HarveySpectre> dol-sen: dol-sen|work: http://codepad.org/B8bDSWHE fixes UAT and FPR both. I think this fixes all the issues. I have never seen a UAT record though, how can I trigger it for testing?
2016-06-13 07:50:03<@dol-sen> I don't know offhand
2016-06-13 07:50:21<@dol-sen> probably have to do some special config for the key
2016-06-13 08:09:33< HarveySpectre> dol-sen: alright! If the change looks good, I'll do a PR to fix the git HEAD
2016-06-13 08:09:49<@dol-sen> yup
2016-06-13 08:09:55<@dol-sen> go for it
2016-06-13 08:29:53< HarveySpectre> Err, git won't let me use the same branch for doing a PR now.
2016-06-13 08:29:56< HarveySpectre> github*
2016-06-13 08:30:38< HarveySpectre> ah maybe i need to sync my fork first
2016-06-13 08:56:39< HarveySpectre> https://github.com/dol-sen/pyGPG/pull/6 Pull request fixes the current conditions.
2016-06-13 08:56:51< HarveySpectre> Please review it and if everything looks good, pull it.
2016-06-13 08:56:53< HarveySpectre> Thanks
2016-06-13 08:57:09<@dol-sen> ok, I will in the morning, going to bed in a few
2016-06-13 09:00:41< HarveySpectre> dol-sen: Good night
2016-06-13 09:00:53<@dol-sen> good night/day
2016-06-13 12:05:45<+dastergon> quite interesting https://github.com/littlebee/git-time-machine
2016-06-13 12:14:33< ashmew2> dastergon, looks good!
2016-06-13 12:15:24<+dastergon> ashmew2: I really like how the Atom is evolving
2016-06-13 12:16:08< ashmew2> I haven't used it, but I've only heard good stuff about it so far.
2016-06-13 12:16:18< ashmew2> Plus it looks like it does a neater job than Sublime
2016-06-13 12:16:36<+dastergon> there are tons of plugins and packages
2016-06-13 12:17:09< ashmew2> maybe fix some https://github.com/littlebee/git-time-machine/issues :D
2016-06-13 12:17:22< ashmew2> dastergon, Atom is your primary editor?
2016-06-13 12:18:50<+dastergon> ashmew2: nope, I use vim
2016-06-13 12:19:38<+dastergon> but ocasionally I use Atom to write some code there
2016-06-13 12:20:04< ashmew2> good change, I feel like I need some graphics too in life :/
2016-06-13 12:20:50<+dastergon> the Electron framework has started to take over the Desktop apps
2016-06-13 12:21:31<+dastergon> Nylas/N1 looks a very promising mail client
2016-06-13 12:22:19< ashmew2> dastergon, no wonder Gnome allowed JS apps :)
2016-06-13 12:22:40< ashmew2> It's good to see how the web is blurring the lines now..bad for security maybe...maybe
2016-06-13 12:26:50< ashmew2> I started using mutt for email a while ago, it's pretty decent
2016-06-13 20:12:45<+dastergon> dol-sen: K_F I reead the gsoc proposal again today and I noticed that the user-specified GPG specs are higher than the key upload function
2016-06-13 20:13:02<+dastergon> be we could switch the tasks so we can finish all the gkeys related actions before midterm eval
2016-06-13 20:13:07<+dastergon> but*
2016-06-13 20:14:02<+K_F> what is the current state on using it for verification? that should go before both of those
2016-06-13 20:14:43<+K_F> granted that is more portage specific, meta-manifest verification 
2016-06-13 20:16:13<+dastergon> K_F: meta-manifest is post-midterm eval
2016-06-13 20:17:04<+dastergon> aeroniero:  +K_F | what is the current state on using it for verification? that should go before both of those
2016-06-13 20:18:58<+K_F> iirc the fetch seed verifies correctly, and it automatically detects the file verification nick matches by issuer ID from the signature
2016-06-13 20:19:15<+K_F> including signing subkeys
2016-06-13 20:20:53<+K_F> or not
2016-06-13 20:21:17<+dastergon> hmm I don't remember
2016-06-13 20:22:00<+dastergon> when dol-sen is up we could set a list for the required actions to be completed for a next gkeys release
2016-06-13 20:22:35 * dol-sen is up
2016-06-13 20:22:38<+dastergon> I mean, we can live for now if the user can't specify a custom format
2016-06-13 20:22:44<+dastergon> for the GPG
2016-06-13 20:22:54 * dol-sen just finished his first meeting of the day
2016-06-13 20:23:13<+dastergon> dol-sen: how long does it last?
2016-06-13 20:23:22<@dol-sen> custom spec is not a priority right now
2016-06-13 20:23:27<+dastergon> y
2016-06-13 20:23:50<@dol-sen> the on at 11:00 my time about 15 min.
2016-06-13 20:24:06<+dastergon> scrum-format meeting?
2016-06-13 20:24:07<@dol-sen> then one in 37 min maybe 30 min.
2016-06-13 20:24:07<+K_F> https://download.sumptuouscapital.com/gentoo/gsoc/verify.txt
2016-06-13 20:24:22<@dol-sen> google hangouts
2016-06-13 20:24:22<+dastergon> nice
2016-06-13 20:24:57<+K_F> seems lookup is broken again
2016-06-13 20:27:40<+K_F> 20:26 <@K_F> actually another failure added as well
2016-06-13 20:27:40<+K_F> 20:26 <@K_F> https://download.sumptuouscapital.com/gentoo/gsoc/verify.txt
2016-06-13 20:27:40<+K_F> 20:26 <@K_F> seems it even fails to verify when specifying category and nick, 
2016-06-13 20:27:40<+K_F>              so its not restricted to lookup failure
2016-06-13 20:29:54<+dastergon> aeroniero_: can you take a look at the verify action ?
2016-06-13 20:30:12<+dastergon> finish up your work for today, then give it a look
2016-06-13 20:38:37<+dastergon> aeroniero33_: I hope you get the messages above
2016-06-13 20:40:45< aeroniero33_> i will have the backlog on my pc at home but I am out  right now and missed the last 10 mins cause of internet problems :/
2016-06-13 20:54:41<@dol-sen> K_F, verify seems to be working for me
2016-06-13 20:54:58<@dol-sen> at least I can manually verify the seed file
2016-06-13 20:55:25<@dol-sen> I don't have anything else handy atm to test
2016-06-13 20:55:33<+K_F> dol-sen: https://download.sumptuouscapital.com/gentoo/gsoc/testfile.txt
2016-06-13 20:55:38<+K_F> https://download.sumptuouscapital.com/gentoo/gsoc/testfile.txt.asc
2016-06-13 20:57:49<+K_F> I just signed that test file..
2016-06-13 20:57:53<@dol-sen> bad connection getting the textfile, .asc was fine
2016-06-13 20:58:02<+K_F> huh?
2016-06-13 20:58:03<@dol-sen> ah finally
2016-06-13 20:58:11<+K_F> thats weird..
2016-06-13 20:58:11<@dol-sen> real slow response
2016-06-13 20:58:27<+K_F> not experiencing any issues here atm
2016-06-13 20:58:29<@dol-sen> anyway, time for another meeting
2016-06-13 20:58:32<+K_F> have fun
2016-06-13 20:59:44< aeroniero__> dastergon: what do you mean by verify action?
2016-06-13 21:00:15< aeroniero__> for fetch-seed?
2016-06-13 21:00:39<+dastergon> check K_F's pastebin
2016-06-13 21:01:38<+dastergon> aeroniero__: https://github.com/gentoo/gentoo-keys/blob/9e06ed9f3629af7809a2f5bbfcea8458ca7b9d15/gkeys/gkeysgpg/actions.py#L40
2016-06-13 21:02:15<+dastergon> wrong URL
2016-06-13 21:02:18<+dastergon> https://github.com/gentoo/gentoo-keys/blob/9e06ed9f3629af7809a2f5bbfcea8458ca7b9d15/gkeys/gkeys/gkeysinterface.py#L60
2016-06-13 21:02:20<+dastergon> that's the correct
2016-06-13 21:03:10< aeroniero__> fyi, I used to have a problem with the verification too but it worked when I updated ssl-fetch to 9999
2016-06-13 21:03:45< aeroniero__> but I will try in right now
2016-06-13 21:09:22<+K_F> https://download.sumptuouscapital.com/gentoo/gsoc/gkeys-output.txt is debug output
2016-06-13 21:09:54<+K_F> its running --debug on the main file instead of doing a proper --verify
2016-06-13 21:10:05<+K_F> so finds no gnupg data (it would only do that if inline signed)
2016-06-13 21:10:22<+K_F> also seems to be missing --batch argument
2016-06-13 21:11:09<+K_F> actually succeeds when just doing
2016-06-13 21:11:42<+K_F> https://download.sumptuouscapital.com/gentoo/gsoc/verify2.txt
2016-06-13 21:11:57<+K_F> so might just be user error since I haven't tried it in a while... but it certainly needs testing in some scenarios :)
2016-06-13 21:13:38<+K_F> output of that is a bit weird anyways, as the actual file to be verified is /home/kristianf/testfile.txt
2016-06-13 21:13:48<+K_F> and here the no batch mode come in, that part should fial
2016-06-13 21:13:49<+K_F> fail*
2016-06-13 21:14:40<+K_F> actually a difference in behavior between --verify and --decrypt there it seems
2016-06-13 21:14:46<+K_F> gpg: assuming signed data in 'testfile.txt'
2016-06-13 21:15:03<+K_F> that is explicitly disabled in --batch mode for --verify as it opens up a few attack vectors
2016-06-13 21:15:34<+K_F> (mainly if there is both a file.bin and file.bin.asc but file.bin.asc actually contains clearsig, not a detached sig, and user then perform installing file.bin that is payload)
2016-06-13 23:08:28<+K_F> ehrm, re-reading what I said up here, the --debug should be --decrypt :)
2016-06-13 23:25:17< ashmew2> Morning guys