[06:05] <infinity> Querying Debian BTS for reports on libprelude (source)...
[06:05] <infinity> Unable to connect to Debian BTS (error: "TypeError("fixer() missing 1 required positional argument: 'check_hostname'",)"); continue [y|N|?]?
[06:05] <infinity> doko, mwhudson: ^-- Does reportbug need a merge/fix for newer python bits?
[06:31] <doko> infinity: where do you see that?
[07:25] <mwhudson> infinity: well isn't that great
[08:34] <doko> coreycb: please could you have a look at the murano sync/merge and look at the autopkg test failures?
[08:37] <doko> coreycb: same for ironic, libcloud
[08:37] <doko> jamespage: ^^^
[10:08] <handsome_feng> Hi, Does anyone know how to unpack and repack the initrd? cpio -idv < ../initrd.img only got a AuthenticAMD.bin; and 'dd if=initrd bs=xxxx | lz4 | cpio -tdv | head' didn't work too.
[10:15] <TJ-> handsome_feng: "unmkinitramfs"
[10:15] <seb128> handsome_feng, unsure if that's still current/valid, but https://wiki.ubuntu.com/CustomizeLiveInitrd
[10:15] <TJ-> handsome_feng: you're dealing with an image that has an early-prefix for microcode on it
[10:19] <handsome_feng> TJ-, seb128 : Thanks! unmkinitramfs works and BTW the wiki page is out of date :)
[10:20] <seb128> handsome_feng, would be nice to update it if you have some free cycle for that :)
[10:21] <TJ-> seb128: I've been waiting to do some Wiki editing but it seems to take an age to get approved to the wiki editors team
[10:21] <TJ-> by the time it gets approved I'll have forgotten what it was I intended to edit :)
[10:21] <seb128> that seems suboptimal :/
[10:22] <seb128> unsure who can approve wiki editor nowadays
[10:22] <TJ-> oh yeah - malware at the target of some links
[10:22] <seb128> ?
[10:23] <TJ-> domains expire/rot, get taken over by operators hosting malware payloads
[10:23] <seb128> popey, ^ you might know who is approving wiki-editor membership?
[10:23] <seb128> TJ-, right, I think I lack some context, why are you talking about that now?
[10:24] <TJ-> seb128: that's reminding me what I wanted to edit to fix; a user reported it in #ubuntu a couple weeks ago
[10:24] <seb128> TJ-, I was just saying that I'm unsure who is reviewing the member-ship requests to approve them, so who to ping to help you getting edit rights
[10:24] <seb128> let's see if popey can help
[10:26] <popey> seb128: i can do that
[10:26] <seb128> popey, hey, ah nice :)
[10:26] <popey> done
[10:26] <seb128> thx!
[10:26] <seb128> TJ-, ^
[10:27]  * TJ- does a happy dance :)
[10:27] <handsome_feng> seb128: Sure, I will do it when I have time. :)
[12:35] <rbasak> vorlon: the git-ubuntu importer service won't restart because it is running on Xenial and using the ubuntu-keyring package, and the archive now has a signature for which it doesn't have a public key. I guess there are currently no plans to SRU updates to this package?
[12:36] <rbasak> I'm not sure how to handle this general case.
[12:36] <rbasak> ISTR there was some reason git-ubuntu needed every key used in Debian and Ubuntu ever.
[12:37] <rbasak> But I don't want to have to release upgrade the git-ubuntu importer service host every time there's a key rotation.
[12:55] <coreycb> doko: jamespage: i'll take a look at those.
[12:57] <coreycb> vorlon: thanks and no problem on the delay. there is charm support going on for octavia that ramped up recently and shined light on octavia-dashboard.
[13:07] <rbasak> "ISTR there was some reason git-ubuntu needed every key used in Debian and Ubuntu ever." -> Now I think about it, it might just be for all supported releases.
[13:36] <rbasak> ahasenack, cpaelzer: may I have your opinion please on my proposed approach in bug 1801725? This is for an upcoming fix to git-ubuntu, without which the importer service is down.
[13:43] <ahasenack> rbasak: wasn't something similar done already in e1b4cd8c9c488a0403f6efecd2cdf3748aa85963 for when bionic was released?
[13:43] <ahasenack> it links to https://bugs.launchpad.net/bugs/1752656
[13:43] <rbasak> ahasenack: aha. Perfect. Thanks!
[13:43] <rbasak> I guess I'm bumping those up then.
[13:44] <ahasenack> +1
[13:54] <xnox> rbasak, ahasenack - please do not duplicate work w.r.t. 2018 key update only. irrespective of the acient bug asking for effectivly `sru everything all the time`
[13:55] <xnox> rbasak, also your guess is wrong =)
[13:55] <xnox> however, i was not planning to go further than bionic. because debootstrap in xenial is not good enough to bootstrap disco.
[13:56] <xnox> commented on https://bugs.launchpad.net/usd-importer/+bug/1801725
[13:56] <xnox> rbasak, ahasenack - also it should be normal for only one signature out of the two valid.... that's why we have dual signing.
[13:58] <ahasenack> xnox: gpgv doesn't like it, exits status 2
[13:58] <rbasak> xnox: "Thus imho this is a bug in the importer if it requires all keys." -> it's a problem with gpgv then.
[13:58] <rbasak> (or a feature request in gpgv at least)
[13:59] <xnox> rbasak, ahasenack - do you have the full cmdline you execute? and/or where is this code at?
[13:59] <xnox> i believe we managed to fix this right; using gpgv; for e.g. ubuntu-release-upgrader
[14:00] <rbasak> xnox: https://git.launchpad.net/usd-importer/tree/gitubuntu/apt_repo.py#n85
[14:01] <xnox> rbasak, ahasenack - gpgv should be able to return signed output, which should be trustworthy, irrespective of errorcodes. Cause full untrusted stuff should return nothing in stdout. Or something along those lines.
[14:01] <xnox> thanks, let me check that out.
[14:01] <rbasak> xnox: and yeah, it's a wheel reinvention. Unfortuantely I couldn't find any library code that did this.
[14:01] <xnox> there is no library for gpg stuff, it sucks.
[14:02] <xnox> and the C embeded netgpg library i found in netbsd is very bad - leaky and not memory safe, thus one is stuck forking to gpg(v)
[14:03] <xnox> rbasak, love the comments there
[14:05] <rbasak> Thanks
[14:06] <rbasak> xnox: so the gpgv manpage (in Xenial at least) says: "The program returns 0 if everything is fine, 1 if at least one signature  was  bad,  and  other error codes for fatal errors."
[14:06] <xnox> yeah
[14:06] <rbasak> xnox: that makes me reluctant to treat non-zero as anything but "everything unverified".
[14:19] <ahasenack> rbasak: do you have gpgv complaining about trustedkeys.kbx too? https://pastebin.ubuntu.com/p/3RPK3F3MxT/
[14:19] <ahasenack> I got that on bionic
[14:20] <ahasenack> I do have the key 3B4FE6ACC0B21F32, just not 871920D1991BC93C
[14:20] <ahasenack> gpg (not gpgv) confirms that, and validates the signature made by 3B4FE6ACC0B21F32
[14:22] <rbasak> ahasenack: no - I'm using --keyring= which I think overrides the default of looking in your ~/.gnupg
[14:22] <ahasenack> anyway passing it the right file via --keyring still returns 2, even though it then verifies one signature correctly
[14:23] <ahasenack> so "no public key" is treated more seriously than "invalid signature" perhaps
[14:24] <xnox> dunno, it seems to me that gpgv is completely broken. as it outputs cleartext, irrespective of signature validity. E.g. i clearsigned something with my own key; validating against archive-keyring; fails to validate any input, yet still spits out output.
[14:24] <xnox> not having any more luck with gpg --decrypt
[14:25] <cjwatson> no library> gpgme exists
[14:25] <cjwatson> (not *necessarily* recommending it, but in some contexts it can be helpful)
[14:25] <rbasak> cjwatson: I meant a library to verify the apt repository
[14:26] <cjwatson> I was replying to
[14:26] <cjwatson> 14:01 <xnox> there is no library for gpg stuff, it sucks.
[14:26] <rbasak> Ah
[14:27] <xnox> well, i do know about gpgme, but yeah i wouldn't call it a `useful` library =) cause it also does fork to gpg. So far i found forking gpg/gpgv by yourself easier.
[14:27] <xnox> and the netpgp was done in the context of no-forking allowed (for pid1)
[14:27] <xnox> granted, thankfully, never released that code.
[14:27] <xnox> the go openpgp library is quite good, for these things.
[14:28] <xnox> but it is in golang.
[14:36] <xnox> hm apt-key verify is just as broken.
[14:38] <Faux> It so is.
[14:41] <infinity> doko, mwhudson: I got that error from reportbug when running 'submittodebian' on disco.
[15:06] <xnox> juliank, how does apt deal with multi-signed apt archives? because e.g. apt-key verify isn't doing what i need/want. Or apt code parses the status-fd stuff?
[15:10] <xnox> juliank, i wonder if i can (re)use /usr/lib/apt/methods/gpgv somehow
[15:28] <TJ-> xnox: how much trouble do you want to go to? Because I've just tested a method locally of splitting the 2 signatures off, then reconstructing with 1 at a time, so gpgv can return 0 if 1 matches (so you'd just loop over each signature).
[15:29] <xnox> TJ-, well, i like the logic that is performed by /usr/lib/apt/methods/gpgv already and it matches what apt itself does.
[15:29] <juliank> xnox: yes, it does parsing, and maybe
[15:29] <juliank> I think the logic is in the library
[15:29] <xnox> TJ-, i wish that to be exposed, in some user-friendly format, perhaps injected to be used as the backend for $ apt-key verify
[15:30] <xnox> juliank, yeap, found it. It parses the logger/status-fd and correctly counts things as we need/want.
[15:30] <xnox> TJ-, ideally i would not want to do signature splitting. As parsing openpgp packets is error prone =/
[15:31] <xnox> TJ-, also imho gpgv in these cases should be returning error code 1, not 2.
[15:31] <xnox> TJ-, i think i will file a gpg/gpgv bug; and also will file an apt bug, cause imho standard ubuntu system should have a gpgv like util out of the box for easy apt-key verification of stuff.
[15:32] <xnox> TJ-, if you pastebin your signature splitting code that should be doable too.
[15:32] <xnox> doable/nice
[15:33] <xnox> or update all the ubuntu-keyring everywhere....
[15:33] <juliank> xnox: you could try to use apt-helper Download-File gpgv:$path too
[15:33] <juliank> Sans upper case
[15:33] <juliank> And with a destination filename
[15:33] <xnox> juliank, oooooh
[15:33] <juliank> I'm not sure what happens, but it's worth trying
[15:34] <xnox> juliank, i didn't find apt-helper yet =) i think this might be what i need.
[15:34] <juliank> /usr/lib/apt
[15:34] <TJ-> xnox: yes, I agree about returning 1 not 2
[15:34] <xnox> juliank, cause by-hand Acquire-URI commands into the stdin of gpgv method were doing the right thing for me.
[15:34] <xnox> juliank, TJ- lunch first, then bugs.
[15:35] <TJ-> xnox: I've 1 last bit to fix-up, figuring out the CRC algorithm used on the signature block :) ... I used gpgsplit to break out the signatures
[17:09] <TJ-> xnox: I give up - no easy way with limited tooling to recreate the PGP signature CRC (and gpgv cannot be told --ignore-crc-error as gpg can)
[17:10] <xnox> =(
[17:10] <xnox> TJ-, parsing status-fd, and/or using the apt's gpgv method imho is the way to go.
[17:10] <xnox> this shall be the master bug to track this: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1801762
[17:10] <TJ-> I fed the crc32 poly and init values into jacksum to recreate, but jacksum is quite heavy (being Java)
[17:47] <juliank> xnox: did you try the helper, does it work? /me curious
[17:48] <xnox> juliank, tried. did not do what i wanted =/ it either `downloads` files without any verification, or fails.
[17:48] <xnox> juliank, maybe i'm not using the right syntax.
[17:48] <xnox> juliank, timed-out trying to work out what it is doing. was going to strace it next.
[17:49] <xnox> maybe i needed to something like gpgv+file:// ?!
[17:54] <juliank> xnox: FWIW, one of src/dest is the keys, the other the data to check (in case of clearsigned, both are the same)
[17:56] <juliank> I think the destination is the key file
[17:56] <juliank> s/key/sig
[17:59]  * juliank disappears again, enough screen time for now :(
[18:20] <TJ-> xnox: I've got a script that works - wraps gpgv. Any good to you? http://iam.tj/projects/ubuntu/gpgv-aptkeys
[18:21] <TJ-> xnox: grr, sent you the symlink version. Use this: http://iam.tj/projects/ubuntu/gpgv-multisig
[19:01] <rbasak> !dmb-ping
[19:18] <slashd> o/
[19:18] <slashd> sorry we changed hours here
[19:42] <tsimonq2> Hi
[19:50] <infinity> coreycb: That ironic update also claims to require python-scciclient>=0.8.0 ... we only have 0.6.1
[19:51] <infinity> coreycb: Similar problem in cosmic, mind you, where it wanted 0.7.2 ..
[19:53] <infinity> coreycb: Might want to fix both those issues.
[19:54] <coreycb> infinity: ok will take a look, thanks for catching that
[19:55] <infinity> coreycb: The cosmic reqs might be a lie (but worth investigating if you need to fix something there or update scciclient or whatever), but the disco one looks legit.  The do_async flag didn't exist before 8.0
[19:57] <coreycb> infinity: can you reject that? I'd like to run dep8 tests and do this via bileto.
[19:59] <infinity> coreycb: Done.
[19:59] <coreycb> infinity: thanks